From nobody Tue Apr 1 00:00: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 999121A6FE7 for ; Tue, 1 Apr 2014 00:00:04 -0700 (PDT) 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 eyVq8MIC18VG for ; Tue, 1 Apr 2014 00:00:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CA9531A6FED for ; Tue, 1 Apr 2014 00:00:02 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 62DE22DC295; Tue, 1 Apr 2014 08:59:58 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 411904C015; Tue, 1 Apr 2014 08:59:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 1 Apr 2014 08:59:58 +0200 From: To: Thomas Nadeau , Zhen Cao Date: Tue, 1 Apr 2014 08:59:55 +0200 Thread-Topic: [sfc] Progression of use case documents in the SFC WG Thread-Index: Ac9NFxGFJ8ad94TiSiyifdPJLmqYmwAX7a2Q Message-ID: <94C682931C08B048B7A8645303FDC9F36F54484863@PUEXCB1B.nanterre.francetelecom.fr> References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> 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.3.31.105114 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/itnqBkNDFo1-iJ3fldCuCnC3OAA Cc: Guichard Jim , "Hongyu Li \(Julio\)" , "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 07:00:04 -0000 Tom, As far as I know determining the consensus does not mean ignore the feedbac= k of the list to a formal poll initiated by the chairs, nor misinterpret th= e discussion that are minuted and available online. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Nadeau >Envoy=E9=A0: lundi 31 mars 2014 21:26 >=C0=A0: Zhen Cao >Cc=A0: Guichard Jim; Hongyu Li (Julio); sfc@ietf.org >Objet=A0: Re: [sfc] Progression of use case documents in the SFC WG > > >On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao wrote: > >> Hello Jim, >> >> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar) >> wrote: >>> You will note that this is not an outright rejection of >>> draft-liu-sfc-use-cases but rather specific questions on the validity o= f >>> adopting the document given that our preference (and the majority of >>> responses from the WG support this view) is to produce standalone >documents >> >> I do not think we can conclude if it is majority now. At least, I did >> not see respect the previous email discussion and London meeting >> minutes... > > I think you misunderstand the job of the WG Chairs. It is their job >to determine consensus, nor yours. > > --Tom > > >> for mobility and data center, and liaise with BBF for broadband. >Therefore, >>> what content is left in the more general document to justify adopting a= s >a >>> separate document? Further if adopted how as a WG can we avoid >duplication >>> of content across multiple documents? >> >> I think Hongyu already justified below. Besides, it also has a cloud >> CPE use case which has not been covered elsewhere. >> >>> 3. It provides an abstraction of common features of all use case, >see >>> section 4 in latest revision draft-liu-sfc-use-cases. This is a good >>> guidance for requirements and architecture derivation. >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Tue Apr 1 00:09: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 C4AE41A6FF9 for ; Tue, 1 Apr 2014 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uskPUrZD90zS for ; Tue, 1 Apr 2014 00:08:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED1AC1A6FF8 for ; Tue, 1 Apr 2014 00:08:28 -0700 (PDT) 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 BCP82488; Tue, 01 Apr 2014 07:08:24 +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; Tue, 1 Apr 2014 08:07:43 +0100 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 08:08:23 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.41]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 1 Apr 2014 15:08:11 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , Zhen Cao Thread-Topic: [sfc] Progression of use case documents in the SFC WG Thread-Index: AQHPSRxfEA3AATWG/kWi/n3iJI0NjZr1qK0AgABs1ICAACeDAIAGH/jQ Date: Tue, 1 Apr 2014 07:08:10 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F1323@szxema506-mbs.china.huawei.com> References: <53358F53.2030409@joelhalpern.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.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KiivH9bu1xzvkzC35wWJP7_P9ag Cc: "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 07:08:55 -0000 What SDO does draft-kumar-sfc-dc-use-cases intend to target? I see the introduction in the document:" Data centers -- enterprise, cloud = or service provider -- deploy service nodes at various points in the network topology" which will over= lap with many SDOs in scopes. Thanks, Yuanlong -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, March 29, 2014 1:25 AM To: Joel M. Halpern; Zhen Cao Cc: sfc@ietf.org Subject: Re: [sfc] Progression of use case documents in the SFC WG Thank you Joel. Yes, this is the approach we plan to take and I see a lot of support for that on the list. On 3/28/14, 11:03 AM, "Joel M. Halpern" wrote: >One aspect in the chairs proposal that struck me has particularly useful >was keeping the use case document for specific partners separate. That >way, it is MUCH easier to liaise with 3GPP or the BBF on the aspects of >the use cases that are important to them. > >Yours, >Joel > >On 3/28/14, 4:34 AM, Zhen Cao wrote: >> Dear Chairs, >> >> I do not know how we come to this conclusion given the below facts >> 1) Email discussion on January, >> http://www.ietf.org/mail-archive/web/sfc/current/msg00966.html, with >> many supports of moving forward the document draft-liu-sfc-use-cases. >> >> 2) London discussion as per >> http://www.ietf.org/proceedings/89/minutes/minutes-89-sfc , where >> several people voice out that we need one document >> >> As for draft-liu-sfc-use-cases, I'd say it is not a simple 'general' >> use cases write-up, actually it has already merged with one mobility >> use case from Med, and it also describe the use cases from the >> abstract point of view, i.e. two angles that try to summarize the >> existing activities. >> >> Technically, one use cases document is much better for people both >> inside and outside to understand the sfc activities better. The >> draft-liu-sfc-use-cases serves this target very well. And many use >> cases are basically the same according the chaining logic, why we need >> so many... >> >> So based on previous discussion both on the list and f2f meeting, I >> am suggesting that we move forward the general document and consider >> other documents in meanwhile as they turn out to be significant. >> >> Many thanks, >> zhen cao >> china mobile >> >>> That leaves: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/, >>>a >>> more general document. But that document includes text on three topics >>>that >>> would be covered in more detail elsewhere (broadband, mobile, and DC). >>>While >>> this document could contain pointers to the other documents, that >>>leaves the >>> document with very little standalone content -- raising the question >>>of what >>> should be done with it, or what content it could incorporate in order >>>to be >>> worthwhile as a standalone document. >>> >>> Thus, the chairs recommendation at this time is: >>> >>> 1) Call for WG adoption of draft-haeffner-sfc-use-case-mobility-00.txt >>>and >>> draft-kumar-sfc-dc-use-cases-00.txt as WG documents (target: >>>informational). >>> >>> 2) Defer action on draft-liu-service-chaining-use-cases and >>> draft-meng-sfc-broadband-usecases per the above discussion. >>> >>> Does this make sense? >>> >>> Jim & Thomas >>> >>> _______________________________________________ >>> 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 nobody Tue Apr 1 03:37: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 A855F1A802C; Tue, 1 Apr 2014 03:37:35 -0700 (PDT) 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 2fvZEjma2p4y; Tue, 1 Apr 2014 03:37:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 180461A802E; Tue, 1 Apr 2014 03:37:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401103734.19995.31059.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 03:37:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/V1o5ClH8v2G_MhNytb_7nDZRSrg Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.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: Tue, 01 Apr 2014 10:37:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-03.txt Pages : 18 Date : 2014-04-01 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 instances 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-03 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 nobody Tue Apr 1 04:42: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 414A01A068C for ; Tue, 1 Apr 2014 04:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9XMTvg0vpHVt for ; Tue, 1 Apr 2014 04:42:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0263C1A0683 for ; Tue, 1 Apr 2014 04:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2772; q=dns/txt; s=iport; t=1396352553; x=1397562153; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bVmVwz0wRmnmvZgYA1O9yHee1XXxLlHUkaPl0q/SnWQ=; b=kElpxBkYKI7FbhlA6r4GTjgRWIhtByiWOvClUbieeD/3JsrzZ8PKGwFF LQxWuJ+Ju8pMrOwZUeTUQMSkS+xY+vXdn2j2zIZ89cvBm/ec+6wSRpELG 9/sVqj/Y0CtoF0EkdwRiZFO9MCDRpWHVLRk/aLNoCC86g06dQb3W6VqGL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFALylOlOtJA2I/2dsb2JhbABZgwY7V7wRhzWBHRZ0giUBAQEEAQEBawsQAgEIEgYnByEGCxQDDgIEAQ0Fh2UDEQ3JfQ2HSxMEjFaBOA4DAR0zB4Q4BJZpgW2MbYVMgzCBcjk X-IronPort-AV: E=Sophos;i="4.97,772,1389744000"; d="scan'208";a="314306144" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 01 Apr 2014 11:42:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s31BgV5l026060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 11:42:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 06:42:30 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Thomas Nadeau" , Zhen Cao Thread-Topic: [sfc] Progression of use case documents in the SFC WG Thread-Index: AQHPSRxfEA3AATWG/kWi/n3iJI0NjZr3cF0AgACkL4CAAY7agIACTFGAgADB2oCAAAvggA== Date: Tue, 1 Apr 2014 11:42:29 +0000 Message-ID: References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F54484863@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F54484863@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.184] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/g1KY3zEWgl_j0houV7rD7mquMvE Cc: "Hongyu Li \(Julio\)" , "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 11:42:38 -0000 Med, Zhen, Let me first say that the chairs are not ignoring yours or anyone else's feedback. No final decisions have been made and I can assure you that the chairs are considering all inputs. There is no attempt to =8Cbias' or =8Cmisinterpret' anything and I would ask that you stop throwing accusation= s such as that around as it is not helping move the discussion forward; we simply want to do what is in the best interests of the WG and enable a process that will aid in moving work forward in a timely manner. On 4/1/14, 2:59 AM, "mohamed.boucadair@orange.com" wrote: >Tom, > >As far as I know determining the consensus does not mean ignore the >feedback of the list to a formal poll initiated by the chairs, nor >misinterpret the discussion that are minuted and available online. > >Cheers, >Med > >>-----Message d'origine----- >>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Nadeau >>Envoy=E9 : lundi 31 mars 2014 21:26 >>=C0 : Zhen Cao >>Cc : Guichard Jim; Hongyu Li (Julio); sfc@ietf.org >>Objet : Re: [sfc] Progression of use case documents in the SFC WG >> >> >>On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao wrote: >> >>> Hello Jim, >>> >>> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar) >>> wrote: >>>> You will note that this is not an outright rejection of >>>> draft-liu-sfc-use-cases but rather specific questions on the validity >>>>of >>>> adopting the document given that our preference (and the majority of >>>> responses from the WG support this view) is to produce standalone >>documents >>> >>> I do not think we can conclude if it is majority now. At least, I did >>> not see respect the previous email discussion and London meeting >>> minutes... >> >> I think you misunderstand the job of the WG Chairs. It is their job >>to determine consensus, nor yours. >> >> --Tom >> >> >>> for mobility and data center, and liaise with BBF for broadband. >>Therefore, >>>> what content is left in the more general document to justify adopting >>>>as >>a >>>> separate document? Further if adopted how as a WG can we avoid >>duplication >>>> of content across multiple documents? >>> >>> I think Hongyu already justified below. Besides, it also has a cloud >>> CPE use case which has not been covered elsewhere. >>> >>>> 3. It provides an abstraction of common features of all use case, >>see >>>> section 4 in latest revision draft-liu-sfc-use-cases. This is a good >>>> guidance for requirements and architecture derivation. >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Tue Apr 1 04:42: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 D8EAD1A8032 for ; Tue, 1 Apr 2014 04:42:42 -0700 (PDT) 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 omb11gyYqRPc for ; Tue, 1 Apr 2014 04:42:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D49691A700E for ; Tue, 1 Apr 2014 04:42:40 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8340E22C77B for ; Tue, 1 Apr 2014 13:42:36 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6D41027C082 for ; Tue, 1 Apr 2014 13:42:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 1 Apr 2014 13:42:36 +0200 From: To: "sfc@ietf.org" Date: Tue, 1 Apr 2014 13:42:23 +0200 Thread-Topic: Remove Section 3 from the problem statement (was RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0Wg== Message-ID: <94C682931C08B048B7A8645303FDC9F36F544849C9@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: 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.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eOosLbh5KETppMjnQV44mSH4-9I Subject: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Tue, 01 Apr 2014 11:42:43 -0000 Dear all, I raised this point to the co-authors but I prefer to raise it also in the = mailing list. I suggest to remove Section 3 from the draft http://tools.ietf.org/html/dra= ft-ietf-sfc-problem-statement-03#section-3, because it goes beyond the prob= lem discussion. That section is more a discussion that should be hosted in = a framework document.=20 Furthermore, some of the points mentioned in that section are questionable = such as the use of metadata and the need of control protocols, etc. Let's a= void mixing objectives and limit the scope of the PS I-D to the identificat= ion to the problems to be solved.=20 Aside not, the WG charter is clear about the scope of the PS I-D: " 1. Problem Statement: This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. " Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >drafts@ietf.org >Envoy=E9=A0: mardi 1 avril 2014 12:38 >=C0=A0: i-d-announce@ietf.org >Cc=A0: sfc@ietf.org >Objet=A0: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Service Function Chaining Working Group >of the IETF. > > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-03.txt > Pages : 18 > Date : 2014-04-01 > >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 instances 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-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 > > >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/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 1 04:44: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 B125C1A6FC9 for ; Tue, 1 Apr 2014 04:44:46 -0700 (PDT) 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 xhHagnVJspx1 for ; Tue, 1 Apr 2014 04:44:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 31B731A0683 for ; Tue, 1 Apr 2014 04:44:45 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id E0161190367 for ; Tue, 1 Apr 2014 13:44:40 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C262B158087 for ; Tue, 1 Apr 2014 13:44:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 1 Apr 2014 13:44:37 +0200 From: To: "sfc@ietf.org" Date: Tue, 1 Apr 2014 13:44:36 +0200 Thread-Topic: Discussion on hidden SFC complexity (was RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn8Gsy3re+mUfTGu7OlGaK0FPRg== Message-ID: <94C682931C08B048B7A8645303FDC9F36F544849CB@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: 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.4.1.90014 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NUvpKMLp4DjsClbyJ0I5YBoC0_E Subject: [sfc] Discussion on hidden SFC complexity (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Tue, 01 Apr 2014 11:44:46 -0000 Re-, Service chaining will come with a cost. The document may include a discussion on potential "hidden" complexity of s= ervice chaining. A typical hidden complexity is located at the "classifier"= : performance issues, complexity to manage entries in the classifiers, look= -up delays, etc.=20 The document should explicit some points that need to be included in the so= lution documents to help assessing to what extent these solution(s) solve t= he problems listed in the Problem Statement.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >drafts@ietf.org >Envoy=E9=A0: mardi 1 avril 2014 12:38 >=C0=A0: i-d-announce@ietf.org >Cc=A0: sfc@ietf.org >Objet=A0: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Service Function Chaining Working Group >of the IETF. > > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-03.txt > Pages : 18 > Date : 2014-04-01 > >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 instances 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-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 > > >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/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 1 04:54: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 E9C771A0697 for ; Tue, 1 Apr 2014 04:54:29 -0700 (PDT) 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 dQ47xuP2I3-H for ; Tue, 1 Apr 2014 04:54:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id A668E1A068C for ; Tue, 1 Apr 2014 04:54:28 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 9BF2D3B44C5; Tue, 1 Apr 2014 13:54:24 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 7BCDD180067; Tue, 1 Apr 2014 13:54:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 1 Apr 2014 13:54:24 +0200 From: To: "Jim Guichard (jguichar)" , Thomas Nadeau , Zhen Cao Date: Tue, 1 Apr 2014 13:54:23 +0200 Thread-Topic: [sfc] Progression of use case documents in the SFC WG Thread-Index: AQHPSRxfEA3AATWG/kWi/n3iJI0NjZr3cF0AgACkL4CAAY7agIACTFGAgADB2oCAAAvggP//8MhA Message-ID: <94C682931C08B048B7A8645303FDC9F36F544849DC@PUEXCB1B.nanterre.francetelecom.fr> References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F54484863@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="windows-1258" 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.4.1.90014 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_iz8Pclj1gkTLXTcy52eQwhUn3E Cc: "Hongyu Li \(Julio\)" , "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 11:54:30 -0000 Re-, There were no accusations from my side; only a reminder of the process and = what is minuted and available publically.=20 Cheers, Med >-----Message d'origine----- >De=A0: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Envoy=E9=A0: mardi 1 avril 2014 13:42 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Thomas Nadeau; Zhen Cao >Cc=A0: Hongyu Li (Julio); sfc@ietf.org >Objet=A0: Re: [sfc] Progression of use case documents in the SFC WG > >Med, Zhen, > >Let me first say that the chairs are not ignoring yours or anyone else's >feedback. No final decisions have been made and I can assure you that the >chairs are considering all inputs. There is no attempt to =8Cbias' or >=8Cmisinterpret' anything and I would ask that you stop throwing accusatio= ns >such as that around as it is not helping move the discussion forward; we >simply want to do what is in the best interests of the WG and enable a >process that will aid in moving work forward in a timely manner. > > >On 4/1/14, 2:59 AM, "mohamed.boucadair@orange.com" > wrote: > >>Tom, >> >>As far as I know determining the consensus does not mean ignore the >>feedback of the list to a formal poll initiated by the chairs, nor >>misinterpret the discussion that are minuted and available online. >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Nadeau >>>Envoy=E9 : lundi 31 mars 2014 21:26 >>>=C0 : Zhen Cao >>>Cc : Guichard Jim; Hongyu Li (Julio); sfc@ietf.org >>>Objet : Re: [sfc] Progression of use case documents in the SFC WG >>> >>> >>>On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao wrote= : >>> >>>> Hello Jim, >>>> >>>> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar) >>>> wrote: >>>>> You will note that this is not an outright rejection of >>>>> draft-liu-sfc-use-cases but rather specific questions on the validity >>>>>of >>>>> adopting the document given that our preference (and the majority of >>>>> responses from the WG support this view) is to produce standalone >>>documents >>>> >>>> I do not think we can conclude if it is majority now. At least, I did >>>> not see respect the previous email discussion and London meeting >>>> minutes... >>> >>> I think you misunderstand the job of the WG Chairs. It is their job >>>to determine consensus, nor yours. >>> >>> --Tom >>> >>> >>>> for mobility and data center, and liaise with BBF for broadband. >>>Therefore, >>>>> what content is left in the more general document to justify adopting >>>>>as >>>a >>>>> separate document? Further if adopted how as a WG can we avoid >>>duplication >>>>> of content across multiple documents? >>>> >>>> I think Hongyu already justified below. Besides, it also has a cloud >>>> CPE use case which has not been covered elsewhere. >>>> >>>>> 3. It provides an abstraction of common features of all use case= , >>>see >>>>> section 4 in latest revision draft-liu-sfc-use-cases. This is a good >>>>> guidance for requirements and architecture derivation. >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> From nobody Tue Apr 1 04:59: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 670521A0697 for ; Tue, 1 Apr 2014 04:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 n6uXuzWGgtrl for ; Tue, 1 Apr 2014 04:59:29 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9192C1A068C for ; Tue, 1 Apr 2014 04:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4984; q=dns/txt; s=iport; t=1396353566; x=1397563166; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D9kUGXxE5eKtnZSIjcVcOJwObaConfHIVp2KiUn7Wus=; b=Ltc9WbHeqY9dS7Ts2VjoZix67T2hPPxkzCA+WeMOAsEEFgRZ37PWbuLn kgcmGo8slm4vO1XoI6aIvJUYBbPCAgZF6n+t6L73GVF26n12UlsHUfBl/ WcVmiEz1bFQmdLsQ7ji8SrJh4YMP2hXObocsxPTxqpKhF9Q5u/TQ6c0on E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAA6pOlOtJV2Z/2dsb2JhbABZgwY7V4MKuQqHNRmBBBZ0giUBAQEEAQEBIBE6CxACAQgSBgICIwMCAgIfBgsUAQIOAgQBDQWHZQMRDa5mmwYNh0sTBIEpiy2BOA4DAVAHgm+BSQSWaYFtjG2FTIMwgXI5 X-IronPort-AV: E=Sophos;i="4.97,772,1389744000"; d="scan'208";a="31944640" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 01 Apr 2014 11:59:24 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s31BxNPu028962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 11:59:23 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 06:59:22 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Thomas Nadeau" , Zhen Cao Thread-Topic: [sfc] Progression of use case documents in the SFC WG Thread-Index: AQHPSRxfEA3AATWG/kWi/n3iJI0NjZr3cF0AgACkL4CAAY7agIACTFGAgADB2oCAAAvggP//8MhAgAAT84A= Date: Tue, 1 Apr 2014 11:59:21 +0000 Message-ID: References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F54484863@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F544849DC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F544849DC@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.184] Content-Type: text/plain; charset="utf-8" Content-ID: <9EF8F3EF94C98A4DA3F35DE3242ABB13@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iXwSbEqImnMbBzjrq8B-G_XKYaM Cc: "Hongyu Li \(Julio\)" , "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 11:59:31 -0000 VGhhbmsgeW91Lg0KDQpPbiA0LzEvMTQsIDc6NTQgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIg0KPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KDQo+UmUtLA0K Pg0KPlRoZXJlIHdlcmUgbm8gYWNjdXNhdGlvbnMgZnJvbSBteSBzaWRlOyBvbmx5IGEgcmVtaW5k ZXIgb2YgdGhlIHByb2Nlc3MNCj5hbmQgd2hhdCBpcyBtaW51dGVkIGFuZCBhdmFpbGFibGUgcHVi bGljYWxseS4NCj4NCj5DaGVlcnMsDQo+TWVkDQo+DQo+Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPj5EZSA6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lz Y28uY29tXQ0KPj5FbnZvecOpIDogbWFyZGkgMSBhdnJpbCAyMDE0IDEzOjQyDQo+PsOAIDogQk9V Q0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgVGhvbWFzIE5hZGVhdTsgWmhlbiBDYW8NCj4+Q2MgOiBI b25neXUgTGkgKEp1bGlvKTsgc2ZjQGlldGYub3JnDQo+Pk9iamV0IDogUmU6IFtzZmNdIFByb2dy ZXNzaW9uIG9mIHVzZSBjYXNlIGRvY3VtZW50cyBpbiB0aGUgU0ZDIFdHDQo+Pg0KPj5NZWQsIFpo ZW4sDQo+Pg0KPj5MZXQgbWUgZmlyc3Qgc2F5IHRoYXQgdGhlIGNoYWlycyBhcmUgbm90IGlnbm9y aW5nIHlvdXJzIG9yIGFueW9uZSBlbHNlJ3MNCj4+ZmVlZGJhY2suIE5vIGZpbmFsIGRlY2lzaW9u cyBoYXZlIGJlZW4gbWFkZSBhbmQgSSBjYW4gYXNzdXJlIHlvdSB0aGF0IHRoZQ0KPj5jaGFpcnMg YXJlIGNvbnNpZGVyaW5nIGFsbCBpbnB1dHMuIFRoZXJlIGlzIG5vIGF0dGVtcHQgdG8gxZJiaWFz JyBvcg0KPj7Fkm1pc2ludGVycHJldCcgYW55dGhpbmcgYW5kIEkgd291bGQgYXNrIHRoYXQgeW91 IHN0b3AgdGhyb3dpbmcNCj4+YWNjdXNhdGlvbnMNCj4+c3VjaCBhcyB0aGF0IGFyb3VuZCBhcyBp dCBpcyBub3QgaGVscGluZyBtb3ZlIHRoZSBkaXNjdXNzaW9uIGZvcndhcmQ7IHdlDQo+PnNpbXBs eSB3YW50IHRvIGRvIHdoYXQgaXMgaW4gdGhlIGJlc3QgaW50ZXJlc3RzIG9mIHRoZSBXRyBhbmQg ZW5hYmxlIGENCj4+cHJvY2VzcyB0aGF0IHdpbGwgYWlkIGluIG1vdmluZyB3b3JrIGZvcndhcmQg aW4gYSB0aW1lbHkgbWFubmVyLg0KPj4NCj4+DQo+Pk9uIDQvMS8xNCwgMjo1OSBBTSwgIm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iDQo+Pjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PiB3cm90ZToNCj4+DQo+Pj5Ub20sDQo+Pj4NCj4+PkFzIGZhciBhcyBJIGtub3cgZGV0ZXJtaW5p bmcgdGhlIGNvbnNlbnN1cyBkb2VzIG5vdCBtZWFuIGlnbm9yZSB0aGUNCj4+PmZlZWRiYWNrIG9m IHRoZSBsaXN0IHRvIGEgZm9ybWFsIHBvbGwgaW5pdGlhdGVkIGJ5IHRoZSBjaGFpcnMsIG5vcg0K Pj4+bWlzaW50ZXJwcmV0IHRoZSBkaXNjdXNzaW9uIHRoYXQgYXJlIG1pbnV0ZWQgYW5kIGF2YWls YWJsZSBvbmxpbmUuDQo+Pj4NCj4+PkNoZWVycywNCj4+Pk1lZA0KPj4+DQo+Pj4+LS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZSBUaG9tYXMgTmFkZWF1DQo+Pj4+RW52b3nDqSA6IGx1bmRpIDMx IG1hcnMgMjAxNCAyMToyNg0KPj4+PsOAIDogWmhlbiBDYW8NCj4+Pj5DYyA6IEd1aWNoYXJkIEpp bTsgSG9uZ3l1IExpIChKdWxpbyk7IHNmY0BpZXRmLm9yZw0KPj4+Pk9iamV0IDogUmU6IFtzZmNd IFByb2dyZXNzaW9uIG9mIHVzZSBjYXNlIGRvY3VtZW50cyBpbiB0aGUgU0ZDIFdHDQo+Pj4+DQo+ Pj4+DQo+Pj4+T24gTWFyIDMwLCAyMDE0OjQ6MjAgQU0sIGF0IDQ6MjAgQU0sIFpoZW4gQ2FvIDx6 ZWhuLmNhb0BnbWFpbC5jb20+DQo+Pj4+d3JvdGU6DQo+Pj4+DQo+Pj4+PiBIZWxsbyBKaW0sDQo+ Pj4+Pg0KPj4+Pj4gT24gU2F0LCBNYXIgMjksIDIwMTQgYXQgODozMiBQTSwgSmltIEd1aWNoYXJk IChqZ3VpY2hhcikNCj4+Pj4+IDxqZ3VpY2hhckBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4+IFlv dSB3aWxsIG5vdGUgdGhhdCB0aGlzIGlzIG5vdCBhbiBvdXRyaWdodCByZWplY3Rpb24gb2YNCj4+ Pj4+PiBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcyBidXQgcmF0aGVyIHNwZWNpZmljIHF1ZXN0aW9u cyBvbiB0aGUNCj4+Pj4+PnZhbGlkaXR5DQo+Pj4+Pj5vZg0KPj4+Pj4+IGFkb3B0aW5nIHRoZSBk b2N1bWVudCBnaXZlbiB0aGF0IG91ciBwcmVmZXJlbmNlIChhbmQgdGhlIG1ham9yaXR5IG9mDQo+ Pj4+Pj4gcmVzcG9uc2VzIGZyb20gdGhlIFdHIHN1cHBvcnQgdGhpcyB2aWV3KSBpcyB0byBwcm9k dWNlIHN0YW5kYWxvbmUNCj4+Pj5kb2N1bWVudHMNCj4+Pj4+DQo+Pj4+PiBJIGRvIG5vdCB0aGlu ayB3ZSBjYW4gY29uY2x1ZGUgaWYgaXQgaXMgbWFqb3JpdHkgbm93LiBBdCBsZWFzdCwgSSBkaWQN Cj4+Pj4+IG5vdCBzZWUgcmVzcGVjdCB0aGUgcHJldmlvdXMgZW1haWwgZGlzY3Vzc2lvbiBhbmQg TG9uZG9uIG1lZXRpbmcNCj4+Pj4+IG1pbnV0ZXMuLi4NCj4+Pj4NCj4+Pj4JSSB0aGluayB5b3Ug bWlzdW5kZXJzdGFuZCB0aGUgam9iIG9mIHRoZSBXRyBDaGFpcnMuIEl0IGlzIHRoZWlyIGpvYg0K Pj4+PnRvIGRldGVybWluZSBjb25zZW5zdXMsIG5vciB5b3Vycy4NCj4+Pj4NCj4+Pj4JLS1Ub20N Cj4+Pj4NCj4+Pj4NCj4+Pj4+IGZvciBtb2JpbGl0eSBhbmQgZGF0YSBjZW50ZXIsIGFuZCBsaWFp c2Ugd2l0aCBCQkYgZm9yIGJyb2FkYmFuZC4NCj4+Pj5UaGVyZWZvcmUsDQo+Pj4+Pj4gd2hhdCBj b250ZW50IGlzIGxlZnQgaW4gdGhlIG1vcmUgZ2VuZXJhbCBkb2N1bWVudCB0byBqdXN0aWZ5DQo+ Pj4+Pj5hZG9wdGluZw0KPj4+Pj4+YXMNCj4+Pj5hDQo+Pj4+Pj4gc2VwYXJhdGUgZG9jdW1lbnQ/ IEZ1cnRoZXIgaWYgYWRvcHRlZCBob3cgYXMgYSBXRyBjYW4gd2UgYXZvaWQNCj4+Pj5kdXBsaWNh dGlvbg0KPj4+Pj4+IG9mIGNvbnRlbnQgYWNyb3NzIG11bHRpcGxlIGRvY3VtZW50cz8NCj4+Pj4+ DQo+Pj4+PiBJIHRoaW5rIEhvbmd5dSBhbHJlYWR5IGp1c3RpZmllZCBiZWxvdy4gQmVzaWRlcywg aXQgYWxzbyBoYXMgYSBjbG91ZA0KPj4+Pj4gQ1BFIHVzZSBjYXNlIHdoaWNoIGhhcyBub3QgYmVl biBjb3ZlcmVkIGVsc2V3aGVyZS4NCj4+Pj4+DQo+Pj4+Pj4gMy4gICAgICBJdCBwcm92aWRlcyBh biBhYnN0cmFjdGlvbiBvZiBjb21tb24gZmVhdHVyZXMgb2YgYWxsIHVzZQ0KPj4+Pj4+Y2FzZSwN Cj4+Pj5zZWUNCj4+Pj4+PiBzZWN0aW9uIDQgaW4gbGF0ZXN0IHJldmlzaW9uIGRyYWZ0LWxpdS1z ZmMtdXNlLWNhc2VzLiBUaGlzIGlzIGEgZ29vZA0KPj4+Pj4+IGd1aWRhbmNlIGZvciByZXF1aXJl bWVudHMgYW5kIGFyY2hpdGVjdHVyZSBkZXJpdmF0aW9uLg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGlu ZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Tue Apr 1 07:14: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 9EBC51A0861 for ; Tue, 1 Apr 2014 07:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 fk4rn4akb_nz for ; Tue, 1 Apr 2014 07:14:07 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 166D91A06BE for ; Tue, 1 Apr 2014 07:14:06 -0700 (PDT) Received: from [192.168.1.107] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0437C2750C17; Tue, 1 Apr 2014 10:14:02 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FF22074A-D1C8-4277-9CDF-B10A801F8306"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 1 Apr 2014 10:14:08 -0400 Message-Id: <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RhCMnNujyvBO0Qox7HeR-4x1Fjw Cc: "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Tue, 01 Apr 2014 14:14:09 -0000 --Apple-Mail=_FF22074A-D1C8-4277-9CDF-B10A801F8306 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This has come up before, and there seemed to be a lot of folks = who wanted to leave section 3 in the document, but I will let the chairs = make the consensus call. http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html --Tom On Apr 1, 2014:7:42 AM, at 7:42 AM, = wrote: > Dear all, >=20 > I raised this point to the co-authors but I prefer to raise it also in = the mailing list. >=20 > I suggest to remove Section 3 from the draft = http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3, = because it goes beyond the problem discussion. That section is more a = discussion that should be hosted in a framework document.=20 >=20 > Furthermore, some of the points mentioned in that section are = questionable such as the use of metadata and the need of control = protocols, etc. Let's avoid mixing objectives and limit the scope of the = PS I-D to the identification to the problems to be solved.=20 >=20 > Aside not, the WG charter is clear about the scope of the PS I-D: >=20 > " > 1. Problem Statement: This document will provide a summary of the > problem space to be addressed by the SFC working group including > example high-level use cases. > " >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >> drafts@ietf.org >> Envoy=E9 : mardi 1 avril 2014 12:38 >> =C0 : i-d-announce@ietf.org >> Cc : sfc@ietf.org >> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Service Function Chaining Working = Group >> of the IETF. >>=20 >> Title : Service Function Chaining Problem Statement >> Authors : Paul Quinn >> Thomas Nadeau >> Filename : draft-ietf-sfc-problem-statement-03.txt >> Pages : 18 >> Date : 2014-04-01 >>=20 >> 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 instances of such service functions, and the subsequent = "steering" >> of traffic flows through those service functions. >>=20 >> The set of enabled service function chains reflect operator service >> offerings and is designed in conjunction with application delivery >> and service and network policy. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 --Apple-Mail=_FF22074A-D1C8-4277-9CDF-B10A801F8306 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 iQIcBAEBCgAGBQJTOsmwAAoJEPcO+I7eiUJZieUP/Rt1gho43XHwzEdohHFzYYcS PIU2jKWDKkVBuW6SYR/bmMxFFCg9BBSaFG4MFFwJsL+BH609AIVFlb0XxT1M8mAd l7GfXBCzgNQc2mHOYbBZq1N6RROjTbsPPInvhkb2ZaKf7YMVmnOpjbKEdVmlyqTk rozafRvlxM1yEy/hDJ26oslZ6WRjjGWg5vJzpbA2UAClLFptSgh9Qh4QaZhwGBx+ fnf2YlPWXoN8qNknKQyknHdZyJAomrZFoLh7KXQ/I9gONRKxrbENLe/xfbBBQVIB nN8e1e+mDUGqy6mbJIDXnq0IaYYFr9uvXd6Eu/uF2G0F71Qya37nJfAAgTJoR3kn ff2OcsyYSE4njLoL39metOLVp6k97JPYmwAmtJ9D5m+j+6gem+eKDaIZ43IyfrbI rHeibM8AqRmGyAFNOK9bzd5dBN0gg2M3H2HCgi4eLRNt6VB90Z9mQVHqMahmZMoE Fmh8I9Pdc1o+bSfAXM7wYkIZxhxzdBD8hqdNUmaYF2IrIWofbganRQjcbULfeVT8 EOzZlIs2flk3wEWz76d+bNGu7NOCCAzh5P17Cibe9K6LhozOqYp9dfdqcUry+iis orqxdTc4+AqMk6QpJ4ksRY+vHYFmxrNLcAoHAG5xDHQsu+s4eSEZ6/AzFeYWCFn0 4MM3I0aSDXnlSVXWiEXD =qpMl -----END PGP SIGNATURE----- --Apple-Mail=_FF22074A-D1C8-4277-9CDF-B10A801F8306-- From nobody Tue Apr 1 07:24: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 10FBC1A06DB for ; Tue, 1 Apr 2014 07:24:21 -0700 (PDT) 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 8Q9ga-Vc2nnn for ; Tue, 1 Apr 2014 07:24:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id DE86B1A079F for ; Tue, 1 Apr 2014 07:24:18 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 8B1CAC062E; Tue, 1 Apr 2014 16:24:14 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 7300FC806E; Tue, 1 Apr 2014 16:24:14 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 1 Apr 2014 16:24:14 +0200 From: To: Thomas Nadeau Date: Tue, 1 Apr 2014 16:24:13 +0200 Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9NtKTxpmnDcODXSIa8BFZI/HPBRwAARQBQ Message-ID: <94C682931C08B048B7A8645303FDC9F36F54484AE1@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> In-Reply-To: <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.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: 2013.11.19.63615 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/U9bFAejWDt2zKyLBMPnzDVVvZho Cc: "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Tue, 01 Apr 2014 14:24:21 -0000 Re-, Thanks for the pointer but that discussion occurred before the adoption of = the document as a WG item.=20 So, I re-iterate my comment.=20 Cheers, Med >-----Message d'origine----- >De=A0: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >Envoy=E9=A0: mardi 1 avril 2014 16:14 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: sfc@ietf.org >Objet=A0: Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >Action: draft-ietf-sfc-problem-statement-03.txt) > > > This has come up before, and there seemed to be a lot of folks who >wanted to leave section 3 in the document, but I will let the chairs make >the consensus call. > >http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html > > --Tom > > >On Apr 1, 2014:7:42 AM, at 7:42 AM, > wrote: > >> Dear all, >> >> I raised this point to the co-authors but I prefer to raise it also in >the mailing list. >> >> I suggest to remove Section 3 from the draft >http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3, >because it goes beyond the problem discussion. That section is more a >discussion that should be hosted in a framework document. >> >> Furthermore, some of the points mentioned in that section are >questionable such as the use of metadata and the need of control protocols= , >etc. Let's avoid mixing objectives and limit the scope of the PS I-D to th= e >identification to the problems to be solved. >> >> Aside not, the WG charter is clear about the scope of the PS I-D: >> >> " >> 1. Problem Statement: This document will provide a summary of the >> problem space to be addressed by the SFC working group including >> example high-level use cases. >> " >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>> drafts@ietf.org >>> Envoy=E9 : mardi 1 avril 2014 12:38 >>> =C0 : i-d-announce@ietf.org >>> Cc : sfc@ietf.org >>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Service Function Chaining Working Grou= p >>> of the IETF. >>> >>> Title : Service Function Chaining Problem Statement >>> Authors : Paul Quinn >>> Thomas Nadeau >>> Filename : draft-ietf-sfc-problem-statement-03.txt >>> Pages : 18 >>> Date : 2014-04-01 >>> >>> 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 instances 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-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> 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 nobody Tue Apr 1 07:25: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 566201A06DB for ; Tue, 1 Apr 2014 07:25:33 -0700 (PDT) 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 YVKpBGqJb3hb for ; Tue, 1 Apr 2014 07:25:29 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 252061A06BE for ; Tue, 1 Apr 2014 07:25:29 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so9239394qgd.1 for ; Tue, 01 Apr 2014 07:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/hR7mm/cM4I/dUaLFb6OWJ+A9Z7yaCYuYUhJVleEl+A=; b=e/4Pf7RPX2e0T47RHFVcJxTB/Z18/xvYmPnsC+03zhu/DKnRclrDk7ZMVMeSrt1TKL FaRLZTCHTDfmn8qdGlUXdzzA7MDV7FQNliGhOl+pg70ujEMKynSphUN2a3WYojmZs5we Bt37cGvKnHpQ6AdcXLf5fw/czS2FSNTyNDWYKpS7Fw0f1IceGGPz96CZwD2wMorMJYAW XxmJefhyEA69hQXsY3zb1rTBPRvgWElHKBwlMypXKGhXckhLAU9dYQq/iV16+I+Fz1sI Wdl0KikZKEXcLIxphsSxfCfrLK8NRgRYsqkKgUODdPa9hFSHig5PHeLJ1P1Xn39yU7by jxzQ== MIME-Version: 1.0 X-Received: by 10.140.96.118 with SMTP id j109mr2466510qge.109.1396362325393; Tue, 01 Apr 2014 07:25:25 -0700 (PDT) Received: by 10.96.111.169 with HTTP; Tue, 1 Apr 2014 07:25:25 -0700 (PDT) In-Reply-To: References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F54484863@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 1 Apr 2014 22:25:25 +0800 Message-ID: From: Zhen Cao To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a113ac01462068b04f5fbf0f0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HmIP66FjxdeQ2842EMfhfmbbyj4 Cc: Thomas Nadeau , "Hongyu Li \(Julio\)" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 14:25:33 -0000 --001a113ac01462068b04f5fbf0f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There were no accusations from my side either, just trying to make things better. Regards, Zhen Jim Guichard (jguichar) =E4=BA=8E2014=E5=B9=B44=E6=9C= =881=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=E5=86=99=E9=81=93=EF=BC=9A > Med, Zhen, > > Let me first say that the chairs are not ignoring yours or anyone else's > feedback. No final decisions have been made and I can assure you that the > chairs are considering all inputs. There is no attempt to =C5=92bias' or > =C5=92misinterpret' anything and I would ask that you stop throwing accus= ations > such as that around as it is not helping move the discussion forward; we > simply want to do what is in the best interests of the WG and enable a > process that will aid in moving work forward in a timely manner. > > > On 4/1/14, 2:59 AM, "mohamed.boucadair@orange.com " > > wrote: > > >Tom, > > > >As far as I know determining the consensus does not mean ignore the > >feedback of the list to a formal poll initiated by the chairs, nor > >misinterpret the discussion that are minuted and available online. > > > >Cheers, > >Med > > > >>-----Message d'origine----- > >>De : sfc [mailto:sfc-bounces@ietf.org ] De la part de > Thomas Nadeau > >>Envoy=C3=A9 : lundi 31 mars 2014 21:26 > >>=C3=80 : Zhen Cao > >>Cc : Guichard Jim; Hongyu Li (Julio); sfc@ietf.org > >>Objet : Re: [sfc] Progression of use case documents in the SFC WG > >> > >> > >>On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao > > wrote: > >> > >>> Hello Jim, > >>> > >>> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar) > >>> > wrote: > >>>> You will note that this is not an outright rejection of > >>>> draft-liu-sfc-use-cases but rather specific questions on the validit= y > >>>>of > >>>> adopting the document given that our preference (and the majority of > >>>> responses from the WG support this view) is to produce standalone > >>documents > >>> > >>> I do not think we can conclude if it is majority now. At least, I did > >>> not see respect the previous email discussion and London meeting > >>> minutes... > >> > >> I think you misunderstand the job of the WG Chairs. It is their j= ob > >>to determine consensus, nor yours. > >> > >> --Tom > >> > >> > >>> for mobility and data center, and liaise with BBF for broadband. > >>Therefore, > >>>> what content is left in the more general document to justify adoptin= g > >>>>as > >>a > >>>> separate document? Further if adopted how as a WG can we avoid > >>duplication > >>>> of content across multiple documents? > >>> > >>> I think Hongyu already justified below. Besides, it also has a cloud > >>> CPE use case which has not been covered elsewhere. > >>> > >>>> 3. It provides an abstraction of common features of all use cas= e, > >>see > >>>> section 4 in latest revision draft-liu-sfc-use-cases. This is a good > >>>> guidance for requirements and architecture derivation. > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > > > --001a113ac01462068b04f5fbf0f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There were no ac= cusations from my side either, just=C2=A0trying to make things better.
Regards,
= Zhen

Jim Guichard (jguichar) <jguichar@= cisco.com>=E4=BA=8E2014=E5=B9=B44=E6=9C=881=E6=97=A5=E6=98=9F=E6=9C= =9F=E4=BA=8C=E5=86=99=E9=81=93=EF=BC=9A
M= ed, Zhen,

Let me first say that the chairs are not ignoring yours or anyone else'= s
feedback. No final decisions have been made and I can assure you that the chairs are considering all inputs. There is no attempt to =C5=92bias' o= r
=C5=92misinterpret' anything and I would ask that you stop throwing acc= usations
such as that around as it is not helping move the discussion forward; we simply want to do what is in the best interests of the WG and enable a
process that will aid in moving work forward in a timely manner.


On 4/1/14, 2:59 AM, "mohamed.boucadair@ora= nge.com"
<mohamed.boucadair@orange.com> wrote:=

>Tom,
>
>As far as I know determining the consensus does not mean ignore the
>feedback of the list to a formal poll initiated by the chairs, nor
>misinterpret the discussion that are minuted and available online.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : sfc [mailto:sfc-bounces@ietf.org] De l= a part de Thomas Nadeau
>>Envoy=C3=A9 : lundi 31 mars 2014 21:26
>>=C3=80 : Zhen Cao
>>Cc : Guichard Jim; Hongyu Li (Julio); sfc@ietf.org<= br> >>Objet : Re: [sfc] Progression of use case documents in the SFC WG >>
>>
>>On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao <zehn.cao@gmail.com> wrote:
>>
>>> Hello Jim,
>>>
>>> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar)
>>> <jguichar@cisco.com> wrote:
>>>> You will note that this is not an outright rejection of >>>> draft-liu-sfc-use-cases but rather specific questions on t= he validity
>>>>of
>>>> adopting the document given that our preference (and the m= ajority of
>>>> responses from the WG support this view) is to produce sta= ndalone
>>documents
>>>
>>> I do not think we can conclude if it is majority now. At least= , I did
>>> not see respect the previous email discussion and London meeti= ng
>>> minutes...
>>
>> =C2=A0 =C2=A0 =C2=A0I think you misunderstand the job of the WG Ch= airs. It is their job
>>to determine consensus, nor yours.
>>
>> =C2=A0 =C2=A0 =C2=A0--Tom
>>
>>
>>> for mobility and data center, and liaise with BBF for broadban= d.
>>Therefore,
>>>> what content is left in the more general document to justi= fy adopting
>>>>as
>>a
>>>> separate document? Further if adopted how as a WG can we a= void
>>duplication
>>>> of content across multiple documents?
>>>
>>> I think Hongyu already justified below. Besides, it also has a= cloud
>>> CPE use case which has not been covered elsewhere.
>>>
>>>> 3. =C2=A0 =C2=A0 =C2=A0It provides an abstraction of commo= n features of all use case,
>>see
>>>> section 4 in latest revision draft-liu-sfc-use-cases. This= is a good
>>>> guidance for requirements and architecture derivation.
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>

--001a113ac01462068b04f5fbf0f0-- From nobody Tue Apr 1 10:40: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 385801A098F for ; Tue, 1 Apr 2014 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 bOCfIyrr-Buc for ; Tue, 1 Apr 2014 10:40:35 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E0A901A08A3 for ; Tue, 1 Apr 2014 10:40:34 -0700 (PDT) Received: from [192.168.1.107] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id B11452751228; Tue, 1 Apr 2014 13:40:30 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_91A91175-1F15-4197-87EB-B84574BE02A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F544849DC@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 1 Apr 2014 13:40:36 -0400 Message-Id: <7F3C9F6C-9E31-44A3-BA85-3E4E0F01D8C8@lucidvision.com> References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F54484863@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F544849DC@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Je-Gq7V6xPU6Hv10CKBZYgNxUf8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 01 Apr 2014 17:40:37 -0000 --Apple-Mail=_91A91175-1F15-4197-87EB-B84574BE02A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I hardly think you need to remind the co-chairs (or document = editors) of the process. We've all been doing this for quite some time = and know the drill. --Tom On Apr 1, 2014:7:54 AM, at 7:54 AM, = wrote: > Re-, >=20 > There were no accusations from my side; only a reminder of the process = and what is minuted and available publically.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Envoy=E9 : mardi 1 avril 2014 13:42 >> =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Nadeau; Zhen Cao >> Cc : Hongyu Li (Julio); sfc@ietf.org >> Objet : Re: [sfc] Progression of use case documents in the SFC WG >>=20 >> Med, Zhen, >>=20 >> Let me first say that the chairs are not ignoring yours or anyone = else's >> feedback. No final decisions have been made and I can assure you that = the >> chairs are considering all inputs. There is no attempt to =8Cbias' or >> =8Cmisinterpret' anything and I would ask that you stop throwing = accusations >> such as that around as it is not helping move the discussion forward; = we >> simply want to do what is in the best interests of the WG and enable = a >> process that will aid in moving work forward in a timely manner. >>=20 >>=20 >> On 4/1/14, 2:59 AM, "mohamed.boucadair@orange.com" >> wrote: >>=20 >>> Tom, >>>=20 >>> As far as I know determining the consensus does not mean ignore the >>> feedback of the list to a formal poll initiated by the chairs, nor >>> misinterpret the discussion that are minuted and available online. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Nadeau >>>> Envoy=E9 : lundi 31 mars 2014 21:26 >>>> =C0 : Zhen Cao >>>> Cc : Guichard Jim; Hongyu Li (Julio); sfc@ietf.org >>>> Objet : Re: [sfc] Progression of use case documents in the SFC WG >>>>=20 >>>>=20 >>>> On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao = wrote: >>>>=20 >>>>> Hello Jim, >>>>>=20 >>>>> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar) >>>>> wrote: >>>>>> You will note that this is not an outright rejection of >>>>>> draft-liu-sfc-use-cases but rather specific questions on the = validity >>>>>> of >>>>>> adopting the document given that our preference (and the majority = of >>>>>> responses from the WG support this view) is to produce standalone >>>> documents >>>>>=20 >>>>> I do not think we can conclude if it is majority now. At least, I = did >>>>> not see respect the previous email discussion and London meeting >>>>> minutes... >>>>=20 >>>> I think you misunderstand the job of the WG Chairs. It is their = job >>>> to determine consensus, nor yours. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>> for mobility and data center, and liaise with BBF for broadband. >>>> Therefore, >>>>>> what content is left in the more general document to justify = adopting >>>>>> as >>>> a >>>>>> separate document? Further if adopted how as a WG can we avoid >>>> duplication >>>>>> of content across multiple documents? >>>>>=20 >>>>> I think Hongyu already justified below. Besides, it also has a = cloud >>>>> CPE use case which has not been covered elsewhere. >>>>>=20 >>>>>> 3. It provides an abstraction of common features of all use = case, >>>> see >>>>>> section 4 in latest revision draft-liu-sfc-use-cases. This is a = good >>>>>> guidance for requirements and architecture derivation. >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>=20 >=20 >=20 --Apple-Mail=_91A91175-1F15-4197-87EB-B84574BE02A5 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 iQIcBAEBCgAGBQJTOvoUAAoJEPcO+I7eiUJZMpMP+wbwBnD9Hs6LM686kuvCmFHb su1oVkWEirPFttyeNiR1NaNYvyzdWaOCo9udhJzcg64rbFlmI8VA8bbj5HoNhEVv NspFvuG6KBWTTnVBJYzFExgC+dqt8fzcaYEB+k/ztWZeEU2+VARFXDcil8k1tfeN 0a2fcPh2MYB6QuZ9jw81Q9taJGq+MDVksREmPtMoPYgontlWniYK8Lx8mHpR7RS9 TPapdo/KPE43zKlZDGGduQcB/vMO9NJfsYiRQoNJEXWn0LmXPoVmMam2bxq5bK0n hJ9+p1NgeZQJZJXZtVfCrkLymh7DnzZa3eKrxcMxSapPNl1k5Kz5DRAqJRQpPOn8 9DMdyEgFtR0zuecTVxN/CRpUFSSE4Dhalqx8Q+jR25nCxDUHkSjaYK5jW14MHdw8 xeUHcjDcKlCP574jJ0uoL8XcHNN8MiybNDxtZOYjJUZvPLEs0+h2qOK9xoR6N6Yx 8ItONw5or3bDJKNn/rILgMBFnhjVfYTCphskMUuUPvmc9dQ+xzMKb/O7qXWoOuJv 1841w5bjYp5YZ3sCX5pT39+xOb0K7w1RQ+m52VYrVYXHNr1RPlU3qEJgYoIhbcqU u62ST7FVSoOwNTHqdWbwT0yjBCvwtLTS2dtx3wJ2skSdRL7JlhLCOF5FW6XEdEqC 8GKu9AvQCVsBCHQF5NKj =SNJF -----END PGP SIGNATURE----- --Apple-Mail=_91A91175-1F15-4197-87EB-B84574BE02A5-- From nobody Tue Apr 1 11:01:51 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 0C5FE1A09B8 for ; Tue, 1 Apr 2014 11:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FwC4-vqnQasD for ; Tue, 1 Apr 2014 11:01:43 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40CB71A098F for ; Tue, 1 Apr 2014 11:01:43 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 01 Apr 2014 11:01:39 -0700 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, 1 Apr 2014 11:01:38 -0700 From: Kevin Glavin To: "sfc@ietf.org" Thread-Topic: [sfc] A new proposal on a flexible-length service chain header that is transport independent Thread-Index: AQHPTdRt7RbpZC3Vjk29uEqN8IRF/w== Date: Tue, 1 Apr 2014 18:01:38 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D92A718@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_9EA32E60D7600C43B6FE22876DF564C81D92A718SFO1EXCMBXP07nb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8MRa0DkWPcwGDhXukRMAZEVcdE4 Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent 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, 01 Apr 2014 18:01:48 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D92A718SFO1EXCMBXP07nb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cathy et Al. I had a read of your draft, nice flexible use of TLV to support meta data m= oving forwards, I note that it takes a different approach than the NSH draf= t which is focused on a fixed length header. At this early stage, I am unsure what the requirements for such a header ar= e - specifically in its complexity and expandability, do you have any tho= ughts on the subject? Do you see a significant need for large variation in the size and complexit= y of the {SCH} encapsulation? Or is a fixed setup with enumeration within t= he fixed space adequate and potentially more efficient? Its an interesting area and as I think as more details are fleshed out in d= etailing the use cases within the space, it may be possible to get some met= rics to aid in understanding what is required longterm. Thanks Kevin --_000_9EA32E60D7600C43B6FE22876DF564C81D92A718SFO1EXCMBXP07nb_ Content-Type: text/html; charset="us-ascii" Content-ID: <6E06FB5B3A9F3B489A9BE5779C1C04D3@riverbed.com> Content-Transfer-Encoding: quoted-printable
Hi Cathy et Al. 

I had a read of your draft, nice flexible use of TLV to support meta d= ata moving forwards, I note that it takes a different approach than the NSH= draft which is focused on a fixed length header.   

At this early stage, I am unsure what the requirements for such a head= er are -   specifically in its complexity and expandability, do you ha= ve any thoughts on the subject?  
Do you see a significant need for large variation in the size and comp= lexity of the {SCH} encapsulation? Or is a fixed setup with enumeration wit= hin the fixed space adequate and potentially more efficient?   

Its an interesting area and as I think as more details are fleshed out= in detailing the use cases within the space, it may be possible to get som= e metrics to aid in understanding what is required longterm. 

Thanks
Kevin


--_000_9EA32E60D7600C43B6FE22876DF564C81D92A718SFO1EXCMBXP07nb_-- From nobody Tue Apr 1 11:44: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 C0BE31A09C0 for ; Tue, 1 Apr 2014 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 t0dyC4zT4CaA for ; Tue, 1 Apr 2014 11:43:56 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id E16A01A08AC for ; Tue, 1 Apr 2014 11:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4106; q=dns/txt; s=iport; t=1396377832; x=1397587432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vJa/utitaksiy3Til6z+3HOvPAos+jL82c9LutO+uYA=; b=CVrQqC7nXBRLjJv3h59okvoQ/g8kqw2QDkFa9jdO8ns2cWWLgfBobYJ0 3WERac0h7IKqMnsyvRM+I79NTOqGwFXEct3HiWG5IQUr4myvHhRtXcJy7 YRjMUe34vWAiqXKsuNvTB/wB8V3uzp11OiHS3fH8jDul0hd9J6x9PEXPp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFALMIO1OtJV2d/2dsb2JhbABZgwY7UQa8FIc1gRwWdIIlAQEBAwEBAQFiCQsQAgEIDgojBAcnCxQRAgQOBQmHaAgIBdFTF44ZBgEBHDMCBYMkgRQEiR6POIEzkQaBcYE/gWoIFyI X-IronPort-AV: E=Sophos;i="4.97,774,1389744000"; d="scan'208";a="32054072" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 01 Apr 2014 18:43:50 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s31IhmEV016674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 18:43:49 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 13:43:48 -0500 From: "Darrel Lewis (darlewis)" To: Thomas Nadeau Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: AQHPTdpPj0+n9hDOSXOVuZTJi4/0Wg== Date: Tue, 1 Apr 2014 18:43:46 +0000 Message-ID: <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> In-Reply-To: <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.183] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <89E493931101B84BAF040CE65100693C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/e6fIyIz4CgU1AtpvRSxhQuwCoHc Cc: "Darrel Lewis \(darlewis\)" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Tue, 01 Apr 2014 18:44:00 -0000 My opinion has not changed, the section seems useful and I see no reason it= should be removed. -Darrel On Apr 1, 2014, at 7:14 AM, Thomas Nadeau wrote: >=20 > This has come up before, and there seemed to be a lot of folks who wante= d to leave section 3 in the document, but I will let the chairs make the co= nsensus call. >=20 > http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >=20 > --Tom >=20 >=20 > On Apr 1, 2014:7:42 AM, at 7:42 AM, wrote: >=20 >> Dear all, >>=20 >> I raised this point to the co-authors but I prefer to raise it also in t= he mailing list. >>=20 >> I suggest to remove Section 3 from the draft http://tools.ietf.org/html/= draft-ietf-sfc-problem-statement-03#section-3, because it goes beyond the p= roblem discussion. That section is more a discussion that should be hosted = in a framework document.=20 >>=20 >> Furthermore, some of the points mentioned in that section are questionab= le such as the use of metadata and the need of control protocols, etc. Let'= s avoid mixing objectives and limit the scope of the PS I-D to the identifi= cation to the problems to be solved.=20 >>=20 >> Aside not, the WG charter is clear about the scope of the PS I-D: >>=20 >> " >> 1. Problem Statement: This document will provide a summary of the >> problem space to be addressed by the SFC working group including >> example high-level use cases. >> " >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>> drafts@ietf.org >>> Envoy=E9 : mardi 1 avril 2014 12:38 >>> =C0 : i-d-announce@ietf.org >>> Cc : sfc@ietf.org >>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Service Function Chaining Working Grou= p >>> of the IETF. >>>=20 >>> Title : Service Function Chaining Problem Statement >>> Authors : Paul Quinn >>> Thomas Nadeau >>> Filename : draft-ietf-sfc-problem-statement-03.txt >>> Pages : 18 >>> Date : 2014-04-01 >>>=20 >>> 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 instances of such service functions, and the subsequent "steering" >>> of traffic flows through those service functions. >>>=20 >>> The set of enabled service function chains reflect operator service >>> offerings and is designed in conjunction with application delivery >>> and service and network policy. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 >>>=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 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 1 11: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 378961A09D1; Tue, 1 Apr 2014 11:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vZaKHHRFRa-c; Tue, 1 Apr 2014 11:51:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5BB1A09C5; Tue, 1 Apr 2014 11:51:42 -0700 (PDT) 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 BFD87426; Tue, 01 Apr 2014 18:51:38 +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; Tue, 1 Apr 2014 19:50:45 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 19:51:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Tue, 1 Apr 2014 11:51:27 -0700 From: Lucy yong To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: comments RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt Thread-Index: AQHPTZZxaAwh8DeZ/kGNH3auSBeJ/Jr9B8Nw Date: Tue, 1 Apr 2014 18:51:27 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4536C144@dfweml701-chm.china.huawei.com> References: <20140401103734.19995.31059.idtracker@ietfa.amsl.com> In-Reply-To: <20140401103734.19995.31059.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/T4OIy7jr9t2DPk0KpUoSjFACs8Y Cc: "sfc@ietf.org" Subject: [sfc] comments RE: I-D Action: draft-ietf-sfc-problem-statement-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: Tue, 01 Apr 2014 18:51:45 -0000 Here are some comments on this version. 1) The term of Classification entity is used in section 3.4 without definin= g it. IMO: it is good for us to treat this entity as a special SF and add t= he text in 3.3 to clarify that. The specialty is that the entity selects th= e traffic entering a service overlay compared to other SFs receives the tra= ffic from service overlay. 2) Text in abstraction: The set of enabled service function chains reflect = operator service offerings and is designed in conjunction with application = delivery and service and network policy. Suggested text: Text in abstraction: The set of enabled service function ch= ains reflect operator service offerings and are designed in conjunction wit= h application delivery, service, and network policy. 3) Text in 3.1 :=20 Service function chaining utilizes a service specific overlay that creates the service topology. The service overlay provides service function connectivity and is built "on top" of the existing network topology and allows operators to use whatever overlay or underlay they prefer to create a path between service functions, and to locate service functions in the network as needed. Suggested Text: =20 Service function chaining utilizes a service overlay that creates the service topology. The service overlay provides service function connectivity and is built "on top" of the existing network topologies. SFC allows operators to use whatever overlay or underlay to create a path between a service function and service node, service no= des,=20 and to locate service functions in the existing networks as needed. 4) Text in 3.4 Data plane metadata provides the ability to exchange information between classification entities and service functions, between service functions, service functions and classification entities and service nodes, and as such does not provide forwarding information used to deliver packet along the service overlay. Metadata can include the result of antecedent classification, information from external sources or forwarding related data. Service functions utilize metadata, as required, for localized policy decisions. Comments: two paragraphs are conflict. Need to be fixed. If a classificatio= n entity can be seen as a special SF, it can be easily fixed. Thanks, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Tuesday, April 01, 2014 5:38 AM To: i-d-announce@ietf.org Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt 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-03.txt Pages : 18 Date : 2014-04-01 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 instances 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 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/ _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 1 12:16: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 DF05C1A098F for ; Tue, 1 Apr 2014 12:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 s3ggdRM_eJOR for ; Tue, 1 Apr 2014 12:16:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 823331A092A for ; Tue, 1 Apr 2014 12:16:06 -0700 (PDT) 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 BCQ44064; Tue, 01 Apr 2014 19:16:02 +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; Tue, 1 Apr 2014 20:15:09 +0100 Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 20:16:00 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML701-CHM.china.huawei.com ([169.254.3.206]) with mapi id 14.03.0158.001; Tue, 1 Apr 2014 12:15:51 -0700 From: "Louis.Fourie" To: Kevin Glavin , "sfc@ietf.org" Thread-Topic: [sfc] A new proposal on a flexible-length service chain header that is transport independent Thread-Index: AQHPTdRt7RbpZC3Vjk29uEqN8IRF/5r9G2Ew Date: Tue, 1 Apr 2014 19:15:51 +0000 Message-ID: References: <9EA32E60D7600C43B6FE22876DF564C81D92A718@SFO1EXC-MBXP07.nbttech.com> In-Reply-To: <9EA32E60D7600C43B6FE22876DF564C81D92A718@SFO1EXC-MBXP07.nbttech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.109] Content-Type: multipart/alternative; boundary="_000_F50B4ABC6D7E3745BC0AD112C6105A728F7F10SJCEML703CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PfNyY_7l7d_yTl1VpzfLyjGCsg8 Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent 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, 01 Apr 2014 19:16:10 -0000 --_000_F50B4ABC6D7E3745BC0AD112C6105A728F7F10SJCEML703CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kevin, There has been discussion on the need to transport various forms of metadat= a along the service chain. Several different examples have been cited, e.g., = app-id, subscriber-id, etc. This proposal addresses the need for a flexible method of transporting tha= t metadata that would allow for innovation in the chaining of different serv= ices. - Louis From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kevin Glavin Sent: Tuesday, April 01, 2014 11:02 AM To: sfc@ietf.org Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header= that is transport independent Hi Cathy et Al. I had a read of your draft, nice flexible use of TLV to support meta data m= oving forwards, I note that it takes a different approach than the NSH draf= t which is focused on a fixed length header. At this early stage, I am unsure what the requirements for such a header ar= e - specifically in its complexity and expandability, do you have any tho= ughts on the subject? Do you see a significant need for large variation in the size and complexit= y of the {SCH} encapsulation? Or is a fixed setup with enumeration within t= he fixed space adequate and potentially more efficient? Its an interesting area and as I think as more details are fleshed out in d= etailing the use cases within the space, it may be possible to get some met= rics to aid in understanding what is required longterm. Thanks Kevin --_000_F50B4ABC6D7E3745BC0AD112C6105A728F7F10SJCEML703CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kevin,<= /p>

There has been discussion= on the need to transport various forms of metadata

along the service chain. = Several different examples have been cited, e.g., app-id, subscriber-id, et= c.

This proposal  addre= sses the need for a flexible method of transporting that<= /p>

metadata that would allow= for innovation in the chaining  of different services.

-  &n= bsp;       Louis<= /span>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Kevin Glavin
Sent: Tuesday, April 01, 2014 11:02 AM
To: sfc@ietf.org
Cc: Cathy Zhang
Subject: Re: [sfc] A new proposal on a flexible-length service chain= header that is transport independent

 

Hi Cathy et Al. <= /o:p>

 

I had a read of your draft,= nice flexible use of TLV to support meta data moving forwards, I note that= it takes a different approach than the NSH draft which is focused on a fixed length header.   

 

At this early stage, I am u= nsure what the requirements for such a header are -   specifically in = its complexity and expandability, do you have any thoughts on the subject?  

Do you see a significant ne= ed for large variation in the size and complexity of the {SCH} encapsulatio= n? Or is a fixed setup with enumeration within the fixed space adequate and potentially more efficient?   

 

Its an interesting area and= as I think as more details are fleshed out in detailing the use cases with= in the space, it may be possible to get some metrics to aid in understanding what is required longterm. 

 

Thanks

Kevin

 

 

--_000_F50B4ABC6D7E3745BC0AD112C6105A728F7F10SJCEML703CHMchina_-- From nobody Tue Apr 1 13:20: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 C0C4F1A09FE for ; Tue, 1 Apr 2014 13:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FxVbk4Q2jgJY for ; Tue, 1 Apr 2014 13:20:28 -0700 (PDT) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id E58AB1A08C2 for ; Tue, 1 Apr 2014 13:20:28 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 01 Apr 2014 13:20:00 -0700 Received: from SFO1EXC-MBXP07.nbttech.com ([fe80::470:1b85:695b:b44e]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%15]) with mapi id 14.02.0328.009; Tue, 1 Apr 2014 13:20:00 -0700 From: Kevin Glavin To: Louis.Fourie , "sfc@ietf.org" Thread-Topic: [sfc] A new proposal on a flexible-length service chain header that is transport independent Thread-Index: AQHPTdRt7RbpZC3Vjk29uEqN8IRF/5r9G2EwgAAYc4A= Date: Tue, 1 Apr 2014 20:19:59 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D92ABFC@SFO1EXC-MBXP07.nbttech.com> References: <9EA32E60D7600C43B6FE22876DF564C81D92A718@SFO1EXC-MBXP07.nbttech.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.253] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D92ABFCSFO1EXCMBXP07nb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2JhBqvSSE8RdTlWHjaZPeOZ398w Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent 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, 01 Apr 2014 20:20:31 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D92ABFCSFO1EXCMBXP07nb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Louis, > >Several different examples have been cited, e.g., app-id, subscriber-id, e= tc. >This proposal addresses the need for a flexible method of transporting th= at >metadata that would allow for innovation in the chaining of different ser= vices. It would be a worthwhile exercise to collect concrete examples of each of t= he types that you mentioned and categorize them in terms of size and also i= n terms of potential for simultaneous use. On the size issue: * I suspect that app id < uint32 so in the bigger picture its a non issue h= ow its coded. * If we say (mobile) subscriber-id =97 how will people expect this = to be used?, a unique u32 id is an option at one end of the spectrum while = an IMEI (16digits), or an MSISDN (15 digits (I think)) is at the other end = of the spectrum. With IMSI being a 64bit number that falls in the middle of= the spectrum. Fixed encoding suits the short end of the spectrum while TLV suits the lo= nger or variable options, how to do other examples from use cases fall in t= his spectrum? On the issue of potential simultaneous use: My understanding is that SFC is currently targeted at deployments within a = single administrative domain, so the encoded tag only has context within th= at domain. If it only has context within the domain, then you could argue t= hat the context (T) is not providing any information and if the id can be f= ormatted into a fixed length ( L) then all that is interesting is the Value= (V) =97 taking the position that within an administrative domain a single = value namespace with fixed context is all that is needed. To further my questioning, is there a expectation that there will be multip= le independent uses within the same domain, if there is then unique tag id = is important as the same value has the potential to appear in both uses wit= hin the same administrative domain e.g IMEI and MSISDN being used for subsc= riber-id interchangeably. Kevin --_000_9EA32E60D7600C43B6FE22876DF564C81D92ABFCSFO1EXCMBXP07nb_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks Louis, 

>
>Several different examples have been cited, e.g., app-id, su= bscriber-id, etc.

>This proposal  addresses the need for a flexible= method of transporting that

>metadata that would allow for innovation in the chain= ing  of different services.



It would be a worthwhile exercise to collect concrete examples of each of t= he types that you mentioned and categorize them in terms of size and also i= n terms of potential for simultaneous use. 

On the size issue:   
* I su= spect that app id < uint32 so in the bigger picture its a non issue how = its coded. 
        * If we say (mobile) subscriber-id =97 how will= people expect this to be used?, a unique u32 id is an option at one end of= the spectrum while an IMEI (16digits), or an MSISDN (15 digits (I think)) = is at the other end of the spectrum. With IMSI being a 64bit number that falls in the middle of the spectrum.

  Fixed encoding suits the short end of the spectrum while TLV su= its the longer or variable options, how to do other examples from use cases= fall in this spectrum?

On the issue of potential simultaneous use: 

My understanding is that SFC is currently targeted at deployments within a = single administrative domain, so the encoded tag only has context within th= at domain. If it only has context within the domain, then you could argue t= hat the context (T) is not providing any information and if the id can be formatted into a fixed length ( L) th= en all that is interesting is the Value (V) =97 taking the position that wi= thin an administrative domain a single value namespace with fixed context i= s all that is needed. 

To further my questioning, is there a expectation that there will be multip= le independent uses within the same domain, if there is then unique tag id = is important as the same value has the potential to appear in both uses wit= hin the same administrative domain e.g IMEI and MSISDN being used for subscriber-id interchangeably. 

Kevin


--_000_9EA32E60D7600C43B6FE22876DF564C81D92ABFCSFO1EXCMBXP07nb_-- From nobody Tue Apr 1 15:50: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 57BB71A6EE7 for ; Tue, 1 Apr 2014 15:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 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, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Y9Q2pTrlA1-S for ; Tue, 1 Apr 2014 15:50:20 -0700 (PDT) Received: from omr-m03.mx.aol.com (omr-m03.mx.aol.com [64.12.143.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1661A6EF1 for ; Tue, 1 Apr 2014 15:50:20 -0700 (PDT) Received: from mtaout-mab02.mx.aol.com (mtaout-mab02.mx.aol.com [172.26.249.82]) by omr-m03.mx.aol.com (Outbound Mail Relay) with ESMTP id 8E7367000008A; Tue, 1 Apr 2014 18:50:16 -0400 (EDT) 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-mab02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4FFAA3800008D; Tue, 1 Apr 2014 18:50:16 -0400 (EDT) Date: Tue, 1 Apr 2014 18:50:16 -0400 From: "mikebianc@aol.com" To: Cathy.H.Zhang@huawei.com Message-ID: <1516725807.33000.1396392616203.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: <291CC3F9E50E7641901A54E85D0977C6E7B88FB165@MAILR002.mail.lan> <53308576.6030107@acm.org> <5330A283.6050007@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361692@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332E76D.6010809@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E013617DD@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332EBA7.3000100@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361830@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E013619D0@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361A1A@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361B80@MISOUT7MSGUSR9I.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32999_625028812.1396392616202" X-Originating-IP: 10.181.180.74, 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=1396392616; bh=BMGKG00kM7YMtHfaEEZO7/QHCUAD4dnWx0CiZeFun60=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Ybvf+nYG85bgzFzkQuW32/vjLcLVG8fIXrGdexutUVOipz0RddvuMpq6TBRGUsABz qjmoY9ZFx7MMovnc9eWVpH/hnNoUEyR68jYSn4u6Ny/wK8+NCXgSJcg91OadflGFXH 5SgZ6aYhb4NV7tsG2FEeFspUJYcHog71Vo6NR/xg= x-aol-sid: 3039ac1af952533b42a83031 X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-bjrhA1P2ogObufRqA_KJ17Kj3M Cc: sfc@ietf.org Subject: Re: [sfc] SFC encapsulation chain ID 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, 01 Apr 2014 22:50:23 -0000 ------=_Part_32999_625028812.1396392616202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In this case, it is still a hop. =C2=A0The LB VM still has to process (and = "balance") the packets, which incurs a larger penalty than the 500ns (or so= ) of a physical network hop. =C2=A0Additionally, the "hop" that you say is = mitigated is only mitigated if you colocate all of the VMs behind a LB inst= ance with the LB itself, which is not very elastic, requiring one to create= multiple instances of LBs for the same SF, which requires either having in= stances chosen by an SFC classifier (which you are trying to avoid) or intr= oducing a LB in a different location to balance between multiple local LBs = (fronting the SF VM instances), which simply re-introduces the hops that yo= u were trying to mitigate in the first place. =C2=A0I suppose you could imp= lement this in such a way that you had a LB in front of your SFC Classifier= , but I'd have to wrap my head around that some more to see if it even make= s sense. =C2=A0Either way, I don't think this solves what you think it solv= es. Why can't we simply say that the SFC classifier chooses the SFC Path (speci= fic SF instances) and as a matter of implementation, if you would like, you= may construct your chain to be a chain of SF LBs, each with a single insta= nce? =C2=A0That would allow you to scale at the cost of the incremental lat= ency that inherently comes with scaling, but also allow a smaller implement= ation to forgo the LBs and perform the distribution function at the Classif= ier. From: Cathy.H.Zhang@huawei.com To: NAPIERALA, MARIA H,Ron Parker,Joel Halpern Direct,Joel M. Halpern,Erik Nordmark,Kevin J Ma,Dave Dolson,Sumandra Majee cc: sfc@ietf.org Sent: Wednesday, March 26, 2014 Subject: Re: [sfc] SFC encapsulation chain ID Hops can be mitigated by running the LB in the same location as those SF VM= s=20 The connection from LB to those SF VMs is local, not hops.=20 Cathy -----Original Message----- From: NAPIERALA, MARIA H [mailto:mn1921@att.com] Sent: Wednesday, March 26,= 2014 10:57 AMTo: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Hal= pern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra MajeeCc: sfc@ietf.or= gSubject: RE: [sfc] SFC encapsulation chain ID> > If case 1 poses a scalabi= lity problem (eg. there are hundreds of VMs> for a service function), the s= calability issue can be solved by> transforming case 1 into case 2> through= placing a local LB before these VMs and only the LB is viewed> in the chai= n. Introducing additional hop is a service chain translates to delay and co= st. Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop chain= becomes 10-hop chain. In fact, if the LB is a virtual appliance it might h= ave similar scalability issue as the original SF.> In some other deployment= scenario, case 1 might not pose> a scalability issue, and> thus solution/a= rchitecture wise, we should not exclude case 1. To put> it another way, cas= e 1 is only usable in small-scale scenario.> > Cathy> > -----Original Messa= ge-----> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MA= RIA H> Sent: Wednesday, March 26, 2014 8:48 AM> To: Ron Parker; Joel Halper= n Direct; Joel M. Halpern; Erik Nordmark;> Kevin J Ma; Dave Dolson; Sumandr= a Majee> Cc: sfc@ietf.org> Subject: Re: [sfc] SFC encapsulation chain ID> >= Ron,> > I would consider a solution which scales only with assumptions 2. = and> 3. (clusters with internal LB) as limited.> > Maria> > > -----Original= Message-----> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]>= > Sent: Wednesday, March 26, 2014 11:44 AM> > To: NAPIERALA, MARIA H; Joel= Halpern Direct; Joel M. Halpern; Erik> > Nordmark; Kevin J Ma; Dave Dolson= ; Sumandra Majee> > Cc: sfc@ietf.org> > Subject: RE: [sfc] SFC encapsulatio= n chain ID> >> > Maria,> >> > I agree with you that case 1. will only pract= ically scale up to some> > point. =C2=A0=C2=A0 Perhaps, as a service provid= er, you'd choose to avoid the> > whole problem and only deploy service func= tions along the lines of> case> > 2 or case 3. =C2=A0=C2=A0 But, that doesn= 't invalidate the utility of case 1> for> > some other network with some ot= her requirements and constraints.> >> > =C2=A0=C2=A0 Ron> >> >> > -----Orig= inal Message-----> > From: NAPIERALA, MARIA H [mailto:mn1921@att.com]> > Se= nt: Wednesday, March 26, 2014 11:39 AM> > To: Ron Parker; Joel Halpern Dire= ct; Joel M. Halpern; Erik Nordmark;> > Kevin J Ma; Dave Dolson; Sumandra Ma= jee> > Cc: sfc@ietf.org> > Subject: RE: [sfc] SFC encapsulation chain ID> >= > > >> > > 1. A service function is realized by multiple VM's where each V= M> has> > > its own IP address. =C2=A0 In this case the classifier/PDP sees= each VM> as> > a> > > service function instance.> > >> >> > I don't think = this will scale. It was pointed out that the number of> > service paths gro= ws exponentially.> >> >> > > 2. A service function, as above, but some subs= et of VM's is front-> > ended> > > by a load balancer. =C2=A0 There are mul= tiple such subsets and therefore> > > multiple load balancers. =C2=A0 Each = load balancer has its own IP> address> > > and hides the VM IP addresses be= hind it. =C2=A0 In this case, the> > > classifier/PDP sees each load balanc= er as a service function> > instance.> >> > No issue here.> >> > > 3. A se= rvice function is realized by a set of VM's that perform> > > internal load= balancing. =C2=A0 The set of VM's presents a single IP> > address> > > to = the outside to hide the IP addresses of the individual VMs.> The> > > netwo= rk has multiple such clusters. =C2=A0 The classifier/PDP sees each> > > clu= ster as a service function instance.> >> >> >> > >> > >> > > -----Original = Message-----> > > From: NAPIERALA, MARIA H [mailto:mn1921@att.com]> > > Sen= t: Wednesday, March 26, 2014 11:17 AM> > > To: Joel Halpern Direct; Joel M.= Halpern; Erik Nordmark; Kevin J> Ma;> > > Ron Parker; Dave Dolson; Sumandr= a Majee> > > Cc: sfc@ietf.org> > > Subject: RE: [sfc] SFC encapsulation cha= in ID> > >> > > Joel,> > >> > > > The point of the distinction was between = on the one hand load> > > > balancing as part of the chain for the purpose = of selecting an> > > > instance of the actually addressed destination (i.e.= the load> > > balancer> > > > is visible to the tenant and is there for th= e purpose the tenant> > > > request; and on the other hand a load balancer = which is known to> > the> > > > service chaining infrastructure, but whose = purpose to balance> > across> > > > isntances of services whose multiplicit= y is not of concern to the> > > > tenant, only the functionality.> > > >> >= > > Put differently, it is between load balancing as an explicit> > servic= e> > > > and load balancing to enable some service within the service> > > = chaining.> > > >> > >> > >> > > Thanks for clarification.> > > My concern i= s about the latter, i.e., SFC solution must support> load> > > balancing to= multiple service instantiations (e.g., VMs) of a> single> > > service at t= he intermediate service hops. In fact, we need the> latter> > > to support = the former..> > >> > > Maria> > >> > > >> > > > On 3/26/14, 10:56 AM, NAPIE= RALA, MARIA H wrote:> > > > >> > > > >> 1) given the range of load balancin= g behaviors, supprting> > > > >> explicit> > > > load> > > > >> balancers i= n the service chaining (as distinct from supporting> > > load> > > > >> bal= ancers for end users), is significantly complicate> > > > >> > > > > I am n= ot sure I understand this point. Could you explain what> you> > > > mean by= "explicit" load balancer vs. load balancer "for the end> > > users"?> > __= _____________________________________________> sfc mailing list> sfc@ietf.o= rg> https://www.ietf.org/mailman/listinfo/sfc______________________________= _________________sfc mailing listsfc@ietf.orghttps://www.ietf.org/mailman/l= istinfo/sfc ------=_Part_32999_625028812.1396392616202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In this case, i= t is still a hop.  The LB VM still has to process (and "balance") the = packets, which incurs a larger penalty than the 500ns (or so) of a physical= network hop.  Additionally, the "hop" that you say is mitigated is on= ly mitigated if you colocate all of the VMs behind a LB instance with the L= B itself, which is not very elastic, requiring one to create multiple insta= nces of LBs for the same SF, which requires either having instances chosen = by an SFC classifier (which you are trying to avoid) or introducing a LB in= a different location to balance between multiple local LBs (fronting the S= F VM instances), which simply re-introduces the hops that you were trying t= o mitigate in the first place.  I suppose you could implement this in = such a way that you had a LB in front of your SFC Classifier, but I'd have = to wrap my head around that some more to see if it even makes sense.  = Either way, I don't think this solves what you think it solves.
<= br>
Why can't we simply say that the SFC classifier chooses the S= FC Path (specific SF instances) and as a matter of implementation, if you w= ould like, you may construct your chain to be a chain of SF LBs, each with = a single instance?  That would allow you to scale at the cost of the i= ncremental latency that inherently comes with scaling, but also allow a sma= ller implementation to forgo the LBs and perform the distribution function = at the Classifier.




From: Cathy.H.Zhang@huawei.com<C= athy.H.Zhang@huawei.com>
To: NAPIERALA, MARIA H<mn1921@att.= com>,Ron Parker<Ron_Parker@affirmednetworks.com>,Joel Halpern Dire= ct<jmh.direct@joelhalpern.com>,Joel M. Halpern<jmh@joelhalpern.com= >,Erik Nordmark<nordmark@acm.org>,Kevin J Ma<kevin.ma@azukisyst= ems.com>,Dave Dolson<ddolson@sandvine.com>,Sumandra Majee<S.Maj= ee@F5.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Wednesday, March 26, 2014
Subject: Re: [sfc] SFC encapsulation = chain ID

Hops can be mitigated by running the LB in t= he same location as those SF VMs
The connection from LB to those SF VMs= is local, not hops.

Cathy

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

From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
Sent: Wednesday, March 26, 2014 10:57 AM
To: Cathy Zhan= g; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J= Ma; Dave Dolson; Sumandra Majee
Cc: sfc@ietf.org
Subject: RE: [sfc] SFC encapsulation chain ID

>
> If case 1 poses a scalability problem (eg. ther= e are hundreds of VMs
> for a service function), the scala= bility issue can be solved by
> transforming case 1 into c= ase 2
> through placing a local LB before these VMs and on= ly the LB is viewed
> in the chain.

Introducing additional hop is a service chain translates to delay a= nd cost. Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop = chain becomes 10-hop chain.
In fact, if the LB is a virtual = appliance it might have similar scalability issue as the original SF.

> In some other deployment scenario, case 1 migh= t not pose
> a scalability issue, and
> t= hus solution/architecture wise, we should not exclude case 1. To put
> it another way, case 1 is only usable in small-scale scenario.=
>
> Cathy
>
> -----Original Message-----
> From: sfc [mailto:= sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA H
> Se= nt: Wednesday, March 26, 2014 8:48 AM
> To: Ron Parker; Jo= el Halpern Direct; Joel M. Halpern; Erik Nordmark;
> Kevin= J Ma; Dave Dolson; Sumandra Majee
> Cc: sfc@ietf.org
> Subject: Re: [sfc] SFC encapsulation chain ID
= >
> Ron,
>
> I woul= d consider a solution which scales only with assumptions 2. and
> 3. (clusters with internal LB) as limited.
>
> Maria
>
> > -----Origi= nal Message-----
> > From: Ron Parker [mailto:Ron_Parke= r@affirmednetworks.com]
> > Sent: Wednesday, March 26, = 2014 11:44 AM
> > To: NAPIERALA, MARIA H; Joel Halpern = Direct; Joel M. Halpern; Erik
> > Nordmark; Kevin J Ma;= Dave Dolson; Sumandra Majee
> > Cc: sfc@ietf.org
> > Subject: RE: [sfc] SFC encapsulation chain ID
> >
> > Maria,
> >
> > I agree with you that case 1. will only practically sca= le up to some
> > point.    Perhaps, as a ser= vice provider, you'd choose to avoid the
> > whole prob= lem and only deploy service functions along the lines of
>= case
> > 2 or case 3.    But, that doesn't i= nvalidate the utility of case 1
> for
> &= gt; some other network with some other requirements and constraints.
> >
> >    Ron
&g= t; >
> >
> > -----Original Messa= ge-----
> > From: NAPIERALA, MARIA H [mailto:mn1921@att= .com]
> > Sent: Wednesday, March 26, 2014 11:39 AM
> > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; E= rik Nordmark;
> > Kevin J Ma; Dave Dolson; Sumandra Maj= ee
> > Cc: sfc@ietf.org
> > Subject= : RE: [sfc] SFC encapsulation chain ID
> >
> > >
> > > 1. A service function is rea= lized by multiple VM's where each VM
> has
&= gt; > > its own IP address.   In this case the classifier/PDP se= es each VM
> as
> > a
&g= t; > > service function instance.
> > >
> >
> > I don't think this will scale. It= was pointed out that the number of
> > service paths g= rows exponentially.
> >
> >
> > > 2. A service function, as above, but some subset of V= M's is front-
> > ended
> > > by= a load balancer.   There are multiple such subsets and therefore
> > > multiple load balancers.   Each load balancer= has its own IP
> address
> > > and= hides the VM IP addresses behind it.   In this case, the
> > > classifier/PDP sees each load balancer as a service functi= on
> > instance.
> >
= > > No issue here.
> >
> > &g= t; 3. A service function is realized by a set of VM's that perform
> > > internal load balancing.   The set of VM's prese= nts a single IP
> > address
> > >= ; to the outside to hide the IP addresses of the individual VMs.
> The
> > > network has multiple such clust= ers.   The classifier/PDP sees each
> > > clust= er as a service function instance.
> >
&g= t; >
> >
> > >
= > > >
> > > -----Original Message-----
> > > From: NAPIERALA, MARIA H [mailto:mn1921@att.com]> > > Sent: Wednesday, March 26, 2014 11:17 AM
> > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordm= ark; Kevin J
> Ma;
> > > Ron Parker= ; Dave Dolson; Sumandra Majee
> > > Cc: sfc@ietf.org=
> > > Subject: RE: [sfc] SFC encapsulation chain ID=
> > >
> > > Joel,
> > >
> > > > The point of the dis= tinction was between on the one hand load
> > > >= balancing as part of the chain for the purpose of selecting an
> > > > instance of the actually addressed destination (i.e.= the load
> > > balancer
> > >= ; > is visible to the tenant and is there for the purpose the tenant
> > > > request; and on the other hand a load balanc= er which is known to
> > the
> > &g= t; > service chaining infrastructure, but whose purpose to balance
> > across
> > > > isntances of se= rvices whose multiplicity is not of concern to the
> > = > > tenant, only the functionality.
> > > >=
> > > > Put differently, it is between load bala= ncing as an explicit
> > service
> >= ; > > and load balancing to enable some service within the service> > > chaining.
> > > >
> > >
> > >
> &g= t; > Thanks for clarification.
> > > My concern i= s about the latter, i.e., SFC solution must support
> load=
> > > balancing to multiple service instantiations = (e.g., VMs) of a
> single
> > > ser= vice at the intermediate service hops. In fact, we need the
&= gt; latter
> > > to support the former..
> > >
> > > Maria
> >= ; >
> > > >
> > > > = On 3/26/14, 10:56 AM, NAPIERALA, MARIA H wrote:
> > >= ; > >
> > > > >> 1) given the range o= f load balancing behaviors, supprting
> > > > >= ;> explicit
> > > > load
> &g= t; > > >> balancers in the service chaining (as distinct from s= upporting
> > > load
> > > &g= t; >> balancers for end users), is significantly complicate
> > > > >
> > > > > I am = not sure I understand this point. Could you explain what
>= you
> > > > mean by "explicit" load balancer vs.= load balancer "for the end
> > > users"?
>
> ____________________________________________= ___
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
s= fc mailing list
sfc@ietf.org
https://www.ietf.o= rg/mailman/listinfo/sfc
------=_Part_32999_625028812.1396392616202-- From nobody Tue Apr 1 22:46: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 7FF8C1A0136 for ; Tue, 1 Apr 2014 22:46:12 -0700 (PDT) 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 jxbkuS9JhIbp for ; Tue, 1 Apr 2014 22:46:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA21A0137 for ; Tue, 1 Apr 2014 22:46:04 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 69E4A2AC943; Wed, 2 Apr 2014 07:45:59 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3823E15804E; Wed, 2 Apr 2014 07:45:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 2 Apr 2014 07:45:59 +0200 From: To: "Darrel Lewis (darlewis)" , Thomas Nadeau Date: Wed, 2 Apr 2014 07:45:57 +0200 Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: AQHPTdpPj0+n9hDOSXOVuZTJi4/0Wpr90IzQ Message-ID: <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> In-Reply-To: <260A9567-D62C-402E-8579-206A0662CC16@cisco.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.4.2.15115 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DIfbXEEwSHpNE3kX761gTF_zg-o Cc: "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Wed, 02 Apr 2014 05:46:12 -0000 Hi Darell, That text is not related to the description of the problems; it goes beyond= that. That section includes technical points that should be discussed more= in a framework document.=20 I don't understand why that section is useful to understand the problem spa= ce.=20 I still object packaging a problem statement document with unbacked framewo= rk discussion. Cheers, Med >-----Message d'origine----- >De=A0: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >Envoy=E9=A0: mardi 1 avril 2014 20:44 >=C0=A0: Thomas Nadeau >Cc=A0: Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >Objet=A0: Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >Action: draft-ietf-sfc-problem-statement-03.txt) > >My opinion has not changed, the section seems useful and I see no reason i= t >should be removed. > >-Darrel >On Apr 1, 2014, at 7:14 AM, Thomas Nadeau wrote: > >> >> This has come up before, and there seemed to be a lot of folks who >wanted to leave section 3 in the document, but I will let the chairs make >the consensus call. >> >> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >> >> --Tom >> >> >> On Apr 1, 2014:7:42 AM, at 7:42 AM, > wrote: >> >>> Dear all, >>> >>> I raised this point to the co-authors but I prefer to raise it also in >the mailing list. >>> >>> I suggest to remove Section 3 from the draft >http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3, >because it goes beyond the problem discussion. That section is more a >discussion that should be hosted in a framework document. >>> >>> Furthermore, some of the points mentioned in that section are >questionable such as the use of metadata and the need of control protocols= , >etc. Let's avoid mixing objectives and limit the scope of the PS I-D to th= e >identification to the problems to be solved. >>> >>> Aside not, the WG charter is clear about the scope of the PS I-D: >>> >>> " >>> 1. Problem Statement: This document will provide a summary of the >>> problem space to be addressed by the SFC working group including >>> example high-level use cases. >>> " >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>>> drafts@ietf.org >>>> Envoy=E9 : mardi 1 avril 2014 12:38 >>>> =C0 : i-d-announce@ietf.org >>>> Cc : sfc@ietf.org >>>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Service Function Chaining Working >Group >>>> of the IETF. >>>> >>>> Title : Service Function Chaining Problem Statement >>>> Authors : Paul Quinn >>>> Thomas Nadeau >>>> Filename : draft-ietf-sfc-problem-statement-03.txt >>>> Pages : 18 >>>> Date : 2014-04-01 >>>> >>>> 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 instances 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-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 nobody Tue Apr 1 23:00: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 368761A013E for ; Tue, 1 Apr 2014 23:00:50 -0700 (PDT) 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 e9E_2b99YLYW for ; Tue, 1 Apr 2014 23:00:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 096D91A0137 for ; Tue, 1 Apr 2014 23:00:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 60D903246B4; Wed, 2 Apr 2014 08:00:41 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 42460238062; Wed, 2 Apr 2014 08:00:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 2 Apr 2014 08:00:41 +0200 From: To: Thomas Nadeau Date: Wed, 2 Apr 2014 08:00:38 +0200 Thread-Topic: [sfc] Progression of use case documents in the SFC WG Thread-Index: Ac9N0XtCMP9uvDfYSe+g2qbwRZdEzgAZWOjw Message-ID: <94C682931C08B048B7A8645303FDC9F36F54484BAD@PUEXCB1B.nanterre.francetelecom.fr> References: <6EB34CB5D82C4645B826C56144826EA97E9DE1A0@SZXEMA509-MBX.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F54484863@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F544849DC@PUEXCB1B.nanterre.francetelecom.fr> <7F3C9F6C-9E31-44A3-BA85-3E4E0F01D8C8@lucidvision.com> In-Reply-To: <7F3C9F6C-9E31-44A3-BA85-3E4E0F01D8C8@lucidvision.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="windows-1258" 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.4.2.53915 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/muSgzxsuVC3VdZLuI0UBqtw7l6A Cc: "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents in the SFC WG 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, 02 Apr 2014 06:00:50 -0000 Tom, Should we focus on the core discussion topic of this thread rather than div= erting?=20 There are precise objections in this thread and an alternate proposal to pr= oduce "ONE" single use case document to meet the working group charter and = to help collecting data that would be used as an input to the requirements. Cheers, Med >-----Message d'origine----- >De=A0: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >Envoy=E9=A0: mardi 1 avril 2014 19:41 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: sfc@ietf.org >Objet=A0: Re: [sfc] Progression of use case documents in the SFC WG > > > > I hardly think you need to remind the co-chairs (or document editors) >of the process. We've all been doing this for quite some time and know th= e >drill. > > --Tom > > >On Apr 1, 2014:7:54 AM, at 7:54 AM, > wrote: > >> Re-, >> >> There were no accusations from my side; only a reminder of the process >and what is minuted and available publically. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Envoy=E9 : mardi 1 avril 2014 13:42 >>> =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Nadeau; Zhen Cao >>> Cc : Hongyu Li (Julio); sfc@ietf.org >>> Objet : Re: [sfc] Progression of use case documents in the SFC WG >>> >>> Med, Zhen, >>> >>> Let me first say that the chairs are not ignoring yours or anyone else'= s >>> feedback. No final decisions have been made and I can assure you that >the >>> chairs are considering all inputs. There is no attempt to =8Cbias' or >>> =8Cmisinterpret' anything and I would ask that you stop throwing >accusations >>> such as that around as it is not helping move the discussion forward; w= e >>> simply want to do what is in the best interests of the WG and enable a >>> process that will aid in moving work forward in a timely manner. >>> >>> >>> On 4/1/14, 2:59 AM, "mohamed.boucadair@orange.com" >>> wrote: >>> >>>> Tom, >>>> >>>> As far as I know determining the consensus does not mean ignore the >>>> feedback of the list to a formal poll initiated by the chairs, nor >>>> misinterpret the discussion that are minuted and available online. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Nadeau >>>>> Envoy=E9 : lundi 31 mars 2014 21:26 >>>>> =C0 : Zhen Cao >>>>> Cc : Guichard Jim; Hongyu Li (Julio); sfc@ietf.org >>>>> Objet : Re: [sfc] Progression of use case documents in the SFC WG >>>>> >>>>> >>>>> On Mar 30, 2014:4:20 AM, at 4:20 AM, Zhen Cao >wrote: >>>>> >>>>>> Hello Jim, >>>>>> >>>>>> On Sat, Mar 29, 2014 at 8:32 PM, Jim Guichard (jguichar) >>>>>> wrote: >>>>>>> You will note that this is not an outright rejection of >>>>>>> draft-liu-sfc-use-cases but rather specific questions on the >validity >>>>>>> of >>>>>>> adopting the document given that our preference (and the majority o= f >>>>>>> responses from the WG support this view) is to produce standalone >>>>> documents >>>>>> >>>>>> I do not think we can conclude if it is majority now. At least, I di= d >>>>>> not see respect the previous email discussion and London meeting >>>>>> minutes... >>>>> >>>>> I think you misunderstand the job of the WG Chairs. It is their job >>>>> to determine consensus, nor yours. >>>>> >>>>> --Tom >>>>> >>>>> >>>>>> for mobility and data center, and liaise with BBF for broadband. >>>>> Therefore, >>>>>>> what content is left in the more general document to justify >adopting >>>>>>> as >>>>> a >>>>>>> separate document? Further if adopted how as a WG can we avoid >>>>> duplication >>>>>>> of content across multiple documents? >>>>>> >>>>>> I think Hongyu already justified below. Besides, it also has a cloud >>>>>> CPE use case which has not been covered elsewhere. >>>>>> >>>>>>> 3. It provides an abstraction of common features of all use >case, >>>>> see >>>>>>> section 4 in latest revision draft-liu-sfc-use-cases. This is a goo= d >>>>>>> guidance for requirements and architecture derivation. >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >> >> From nobody Wed Apr 2 12:14: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 107251A03A6 for ; Wed, 2 Apr 2014 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Ihe8rqFD9Z0e for ; Wed, 2 Apr 2014 12:14:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4C1A0389 for ; Wed, 2 Apr 2014 12:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5812; q=dns/txt; s=iport; t=1396466066; x=1397675666; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rFxy465anmc1cgtCKOKPMj0mrs0hqeQFEVvddGPMHMc=; b=QClGH8NGxf+0QPNxh9UjOphfZ4ZHw5dG3xSgZHtVIRh7Y4B4m4pMdsAB eouTP12sRwp9QKPPJzMHzxd3BTJEQIlrrw1jK3yiZo3kIL/opRtBxtKIt jHamIlle0qREElMlAV2XfY8upZ+5cF3yBk5+htZfRrNSYvPJH/UfG4Dme U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAM9gPFOtJV2a/2dsb2JhbABZgwY7UQa8M4c1gSEWdIIlAQEBAwEBAQFiCQsFCwIBCA4KIwQHJwsUEQEBBA4FCYdoCAgFzyIXjhkGAQEcMwIFgySBFASJII84gTORBoFxgT+BaggXIg X-IronPort-AV: E=Sophos;i="4.97,782,1389744000"; d="scan'208";a="314651251" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2014 19:14:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s32JEPN8007379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 19:14:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 14:14:24 -0500 From: "Carlos Pignataro (cpignata)" To: Med Boucadair Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAPxz0AAAlqtgAAFyBhgAAcO/WA Date: Wed, 2 Apr 2014 19:14:24 +0000 Message-ID: <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <45DA23AFE336E548AFD79D48925BE8EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/birmkBWh28rXmrYe2a0fMaTgrUQ Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Wed, 02 Apr 2014 19:14:34 -0000 Med, Instead of repeating the argument, please see http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html http://www.ietf.org/mail-archive/web/sfc/current/msg00897.html http://www.ietf.org/mail-archive/web/sfc/current/msg00900.html I would certainly *not* describe Section 3 as an "unbacked framework discus= sion". By the way, looking at the charter for SFC, the word /framework/i ap= pears exactly zero instances. Best, -- Carlos. On Apr 2, 2014, at 1:45 AM, mohamed.boucadair@orange.com wrote: > Hi Darell, >=20 > That text is not related to the description of the problems; it goes beyo= nd that. That section includes technical points that should be discussed mo= re in a framework document.=20 >=20 > I don't understand why that section is useful to understand the problem s= pace.=20 >=20 > I still object packaging a problem statement document with unbacked frame= work discussion. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >> Envoy=E9 : mardi 1 avril 2014 20:44 >> =C0 : Thomas Nadeau >> Cc : Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >> Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >> Action: draft-ietf-sfc-problem-statement-03.txt) >>=20 >> My opinion has not changed, the section seems useful and I see no reason= it >> should be removed. >>=20 >> -Darrel >> On Apr 1, 2014, at 7:14 AM, Thomas Nadeau wrot= e: >>=20 >>>=20 >>> This has come up before, and there seemed to be a lot of folks who >> wanted to leave section 3 in the document, but I will let the chairs mak= e >> the consensus call. >>>=20 >>> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>>=20 >>> --Tom >>>=20 >>>=20 >>> On Apr 1, 2014:7:42 AM, at 7:42 AM, >> wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> I raised this point to the co-authors but I prefer to raise it also in >> the mailing list. >>>>=20 >>>> I suggest to remove Section 3 from the draft >> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3= , >> because it goes beyond the problem discussion. That section is more a >> discussion that should be hosted in a framework document. >>>>=20 >>>> Furthermore, some of the points mentioned in that section are >> questionable such as the use of metadata and the need of control protoco= ls, >> etc. Let's avoid mixing objectives and limit the scope of the PS I-D to = the >> identification to the problems to be solved. >>>>=20 >>>> Aside not, the WG charter is clear about the scope of the PS I-D: >>>>=20 >>>> " >>>> 1. Problem Statement: This document will provide a summary of the >>>> problem space to be addressed by the SFC working group including >>>> example high-level use cases. >>>> " >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>>>> drafts@ietf.org >>>>> Envoy=E9 : mardi 1 avril 2014 12:38 >>>>> =C0 : i-d-announce@ietf.org >>>>> Cc : sfc@ietf.org >>>>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Service Function Chaining Working >> Group >>>>> of the IETF. >>>>>=20 >>>>> Title : Service Function Chaining Problem Statement >>>>> Authors : Paul Quinn >>>>> Thomas Nadeau >>>>> Filename : draft-ietf-sfc-problem-statement-03.txt >>>>> Pages : 18 >>>>> Date : 2014-04-01 >>>>>=20 >>>>> 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 instances of such service functions, and the subsequent "steering" >>>>> of traffic flows through those service functions. >>>>>=20 >>>>> The set of enabled service function chains reflect operator service >>>>> offerings and is designed in conjunction with application delivery >>>>> and service and network policy. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-0= 3 >>>>>=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 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=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 >>>=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 nobody Wed Apr 2 16:34: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 29A641A0016 for ; Wed, 2 Apr 2014 16:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 vP8QDiBspUqA for ; Wed, 2 Apr 2014 16:34:14 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 55A341A000D for ; Wed, 2 Apr 2014 16:34:14 -0700 (PDT) Received: from [172.22.209.194] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s32NXvko015621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Apr 2014 16:33:57 -0700 Message-ID: <533C9E64.5010102@acm.org> Date: Wed, 02 Apr 2014 16:33:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Joel M. Halpern" , Erik Nordmark , Kevin J Ma , Ron Parker , Dave Dolson , Sumandra Majee References: <291CC3F9E50E7641901A54E85D0977C6E7B88FB165@MAILR002.mail.lan> <53308576.6030107@acm.org> <5330A283.6050007@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361692@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332E76D.6010809@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E013617DD@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332EBA7.3000100@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361830@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332F131.1070503@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E013619F6@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E013619F6@MISOUT7MSGUSR9I.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;ELybQr+64xGz5NKVOBdzQA== M;oGunQr+64xGz5NKVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/koK1Fhc4lNHhd6SgvNuDrd45OuU Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC encapsulation chain ID 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, 02 Apr 2014 23:34:18 -0000 On 3/26/14 8:43 AM, NAPIERALA, MARIA H wrote: > The issue is scaling service chaining where many (potentially 100's) of instances of a single service are present and where there is no internal load balancing per service function. > Is this being addressed in the SFC? Maria, I think SFC can at best address a subset of that problem space. The SF might contain operational/run-time state tied to a particular flow/subscriber/tenant. The details of how such state is checkpointed or shared between different instances of the SF (e.g., for HA) is out of scope of SFC AFAIK. In some cases the rules for which packets need to be sent to which instances (that has the above state) can be expressed in the SFC classifier, but in other cases it might not. (In the old web world we had cases like HTTP cookies in SSL encrypted traffic - a load balancer needed to be a SSL termination point to be able to use the HTTP cookie to choose the server. I don't know if there are similar cases in NfV which would require something more than DPI to do correct load balancing.) SFC should be able to handle 100's of instances, but if the SFC needs to respond to the actual load on the instances, then some additional protocol mechanisms (with scaling considerations) might be needed. Sending 1/100 of flows/subscriber to each instance can be done by SFC in isolation, but if different flow's/subscriber's packets generate radically different load on the instances that might not be sufficient. For instance, the SF instances might need to report their load to the SFC load balancer. Regards, Erik > > Maria > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 26, 2014 11:25 AM >> To: NAPIERALA, MARIA H; Erik Nordmark; Kevin J Ma; Ron Parker; Dave >> Dolson; Sumandra Majee >> Cc: sfc@ietf.org >> Subject: Re: [sfc] SFC encapsulation chain ID >> >> Given that we have mechanisms which allow service functions to direct >> modification of the service chain identification (preferably through >> metadata, but that is still under discussion) then it follows that the >> current proposals allow a load balancer which directs the chaining, and >> which modifies the packet if needed to affect external targeting. >> >> While I would prefer and expect that to be rarely used, it is allowed. >> And I do not expect the documents to express a preference (for or >> against my personal preference.) >> >> Given that you agree that we can also do internal load balancing, I >> don't understand what changes you are requesting. >> >> Yours, >> Joel >> >> On 3/26/14, 11:16 AM, NAPIERALA, MARIA H wrote: >>> Joel, >>> >>>> The point of the distinction was between on the one hand load >> balancing >>>> as part of the chain for the purpose of selecting an instance of the >>>> actually addressed destination (i.e. the load balancer is visible to >>>> the >>>> tenant and is there for the purpose the tenant request; and on the >>>> other >>>> hand a load balancer which is known to the service chaining >>>> infrastructure, but whose purpose to balance across isntances of >>>> services whose multiplicity is not of concern to the tenant, only >> the >>>> functionality. >>>> >>>> Put differently, it is between load balancing as an explicit service >>>> and >>>> load balancing to enable some service within the service chaining. >>>> >>> >>> Thanks for clarification. >>> My concern is about the latter, i.e., SFC solution must support load >> balancing to multiple service instantiations (e.g., VMs) of a single >> service at the intermediate service hops. In fact, we need the latter >> to support the former.. >>> Maria >>> >>>> On 3/26/14, 10:56 AM, NAPIERALA, MARIA H wrote: >>>>>> 1) given the range of load balancing behaviors, supprting explicit >>>> load >>>>>> balancers in the service chaining (as distinct from supporting >> load >>>>>> balancers for end users), is significantly complicate >>>>> I am not sure I understand this point. Could you explain what you >>>> mean by "explicit" load balancer vs. load balancer "for the end >> users"? From nobody Thu Apr 3 00:04: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 C54811A0020 for ; Thu, 3 Apr 2014 00:04:01 -0700 (PDT) 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, 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 7ITyVrLwo6oW for ; Thu, 3 Apr 2014 00:03:57 -0700 (PDT) Received: from mc26.lon.server.colt.net (mc26.lon.server.colt.net [212.74.77.106]) by ietfa.amsl.com (Postfix) with ESMTP id ED7CB1A0091 for ; Thu, 3 Apr 2014 00:03:56 -0700 (PDT) Received: from mc26.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B0EA8C0064 for ; Thu, 3 Apr 2014 07:03:21 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc26.lon.server.colt.net (Postfix) with ESMTP id 8B16CC003E for ; Thu, 3 Apr 2014 07:03:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,784,1389740400"; d="scan'208";a="946231" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 03 Apr 2014 09:03:21 +0200 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([10.12.1.3]) with mapi id 14.01.0438.000; Thu, 3 Apr 2014 09:03:20 +0200 From: Nicolas BOUTHORS To: "sfc@ietf.org" Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: AQHPTqXTVNlWHTID2Ei+jxShKmLSkpr/cja0 Date: Thu, 3 Apr 2014 07:03:20 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D43BEB5@LILAS.jungle.qosmos.com> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com>, <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1017-20606.005 X-TM-AS-Result: No--24.421-5.0-31-10 X-imss-scan-details: No--24.421-5.0-31-10 X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1017-20606.005 X-TMASE-Result: 10--24.420600-5.000000 X-TMASE-MatchedRID: nI1cAR4k0HZJtzxaLxhtW5YsKSXWWrsHRvyVHewb0kIs9SDX+kNbCghk lHt5Yr9cxNWi3Apv2E8n8vS3FuJ9txNmUW1dq3Nx4Tzr6T25NkfE+tSSoKDaKZskuXz9GadkMH1 xx17eFtToZBOhqhwyeN8gQRoyC/sCUeg0+48uLr3pnOP6QxEGtgvxMaV6x4s8W+jwVKpqvlJJwB bSn2nnRT1whw4RwAkCFlmrHys+VOsOwH4pD14DsHlMlWV+Ir67QKuv8uQBDjqCTJUvpDBm3FwmG jybF7NfnK6NH0kJeVpxgizGi89MHEv67nTmm9Fn3FqOVb7PDEL2acON9Q+rnuod133eVWP4NVjV q6WuIRSnsg/6AL8LOyOEFEvh6dd9s4QpfGxXuAFX0vBPb36vNjTbofuc5kuvl9UVnK8KIxyH9Yb dz8BzMHUv5fXxlzM9H817pl0C9wySDoYDmYjzLFVN8laWo90M/Hd4CUWIS/E0xNcGN9nK1/GNPW gTrGqskcXTZtYB1vUl9+c89RK6DWC+RjBytve0nVTWWiNp+v86En2bnefhoKXJ9vMysD/C90viw o9jlei36h2hK5rvdn8mA3sDDq0AELDJ6cCL86X9b0xgYrma7dRnEQCUU+jzjoczmuoPCq2UTGVA hB5EbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lQ6k078Ll0tkwBokCAjozlaOgCg Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Thu, 03 Apr 2014 07:04:02 -0000 =0A= The problem statement is focussed specifically on service chaining, As a re= sult I see the benefit of having in section 3 a clear=0A= definition of the key concepts underlying the notion of service chaining th= at will be discussed in the documents produced by the group.=0A= =0A= It provides a scope for the discussions. For example, Data Sharing / Meta= data should probably discussed somewhere in the =0A= requirement and framework documents. Still I believe as written the problem= statement has been instrumental is the decision =0A= to have a Metadata contribution to explore it fully.=0A= =0A= As a result I would vote to keep section 3.=0A= =0A= Nicolas=0A= ________________________________________=0A= From: mohamed.boucadair@orange.com [mohamed.boucadair@orange.com]=0A= Sent: Wednesday, April 02, 2014 7:45 AM=0A= To: Darrel Lewis (darlewis); Thomas Nadeau=0A= Cc: sfc@ietf.org=0A= Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D= Action: draft-ietf-sfc-problem-statement-03.txt)=0A= =0A= Hi Darell,=0A= =0A= That text is not related to the description of the problems; it goes beyond= that. That section includes technical points that should be discussed more= in a framework document.=0A= =0A= I don't understand why that section is useful to understand the problem spa= ce.=0A= =0A= I still object packaging a problem statement document with unbacked framewo= rk discussion.=0A= =0A= Cheers,=0A= Med=0A= =0A= >-----Message d'origine-----=0A= >De : Darrel Lewis (darlewis) [mailto:darlewis@cisco.com]=0A= >Envoy=E9 : mardi 1 avril 2014 20:44=0A= >=C0 : Thomas Nadeau=0A= >Cc : Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org=0A= >Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D= =0A= >Action: draft-ietf-sfc-problem-statement-03.txt)=0A= >=0A= >My opinion has not changed, the section seems useful and I see no reason i= t=0A= >should be removed.=0A= >=0A= >-Darrel=0A= >On Apr 1, 2014, at 7:14 AM, Thomas Nadeau wrote:= =0A= >=0A= >>=0A= >> This has come up before, and there seemed to be a lot of folks who= =0A= >wanted to leave section 3 in the document, but I will let the chairs make= =0A= >the consensus call.=0A= >>=0A= >> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html=0A= >>=0A= >> --Tom=0A= >>=0A= >>=0A= >> On Apr 1, 2014:7:42 AM, at 7:42 AM, =0A= > wrote:=0A= >>=0A= >>> Dear all,=0A= >>>=0A= >>> I raised this point to the co-authors but I prefer to raise it also in= =0A= >the mailing list.=0A= >>>=0A= >>> I suggest to remove Section 3 from the draft=0A= >http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3,= =0A= >because it goes beyond the problem discussion. That section is more a=0A= >discussion that should be hosted in a framework document.=0A= >>>=0A= >>> Furthermore, some of the points mentioned in that section are=0A= >questionable such as the use of metadata and the need of control protocols= ,=0A= >etc. Let's avoid mixing objectives and limit the scope of the PS I-D to th= e=0A= >identification to the problems to be solved.=0A= >>>=0A= >>> Aside not, the WG charter is clear about the scope of the PS I-D:=0A= >>>=0A= >>> "=0A= >>> 1. Problem Statement: This document will provide a summary of the=0A= >>> problem space to be addressed by the SFC working group including=0A= >>> example high-level use cases.=0A= >>> "=0A= >>>=0A= >>> Cheers,=0A= >>> Med=0A= >>>=0A= >>>> -----Message d'origine-----=0A= >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet-=0A= >>>> drafts@ietf.org=0A= >>>> Envoy=E9 : mardi 1 avril 2014 12:38=0A= >>>> =C0 : i-d-announce@ietf.org=0A= >>>> Cc : sfc@ietf.org=0A= >>>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt=0A= >>>>=0A= >>>>=0A= >>>> A New Internet-Draft is available from the on-line Internet-Drafts=0A= >>>> directories.=0A= >>>> This draft is a work item of the Service Function Chaining Working=0A= >Group=0A= >>>> of the IETF.=0A= >>>>=0A= >>>> Title : Service Function Chaining Problem Statement=0A= >>>> Authors : Paul Quinn=0A= >>>> Thomas Nadeau=0A= >>>> Filename : draft-ietf-sfc-problem-statement-03.txt=0A= >>>> Pages : 18=0A= >>>> Date : 2014-04-01=0A= >>>>=0A= >>>> Abstract:=0A= >>>> This document provides an overview of the issues associated with the= =0A= >>>> deployment of service functions (such as firewalls, load balancers)=0A= >>>> in large-scale environments. The term service function chaining is=0A= >>>> used to describe the definition and instantiation of an ordered set=0A= >>>> of instances of such service functions, and the subsequent "steering"= =0A= >>>> of traffic flows through those service functions.=0A= >>>>=0A= >>>> The set of enabled service function chains reflect operator service=0A= >>>> offerings and is designed in conjunction with application delivery=0A= >>>> and service and network policy.=0A= >>>>=0A= >>>>=0A= >>>> The IETF datatracker status page for this draft is:=0A= >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/=0A= >>>>=0A= >>>> There's also a htmlized version available at:=0A= >>>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03=0A= >>>>=0A= >>>> A diff from the previous version is available at:=0A= >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03= =0A= >>>>=0A= >>>>=0A= >>>> Please note that it may take a couple of minutes from the time of=0A= >>>> submission=0A= >>>> until the htmlized version and diff are available at tools.ietf.org.= =0A= >>>>=0A= >>>> Internet-Drafts are also available by anonymous FTP at:=0A= >>>> ftp://ftp.ietf.org/internet-drafts/=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= =0A= =0A= From nobody Thu Apr 3 01:37: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 98EBF1A0120 for ; Thu, 3 Apr 2014 01:37:27 -0700 (PDT) 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 J7_KulfJvXUr for ; Thu, 3 Apr 2014 01:37:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6961A0116 for ; Thu, 3 Apr 2014 01:37:23 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id EECB718C70E; Thu, 3 Apr 2014 10:37:17 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BC30935C06A; Thu, 3 Apr 2014 10:37:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 3 Apr 2014 10:37:17 +0200 From: To: "Carlos Pignataro (cpignata)" Date: Thu, 3 Apr 2014 10:37:15 +0200 Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAPxz0AAAlqtgAAFyBhgAAcO/WAABC7E6A= Message-ID: <94C682931C08B048B7A8645303FDC9F36F547C7083@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> In-Reply-To: <99E5F358-A1A2-4396-892B-61297B352F66@cisco.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: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LnZOgDgj36BqzMCKN6jzBVPfyG0 Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Thu, 03 Apr 2014 08:37:27 -0000 Hi Carlos, Thanks for pointing to these messages.=20 With all due respect, only the first one you cited tries to motivate the ne= ed for such section. But the argument you provided does not make sense to m= e, since it is the role of the charter to do that... not to froze them in a= n RFC.=20 IMHO, the group should be open to any proposal that claim to solve the prob= lems listed in the problem statement.=20 Let us shape a problem statement that is solution-neutral. Cheers, Med >-----Message d'origine----- >De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >Envoy=E9=A0: mercredi 2 avril 2014 21:14 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: Darrel Lewis (darlewis); Tom Nadeau; sfc@ietf.org >Objet=A0: Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >Action: draft-ietf-sfc-problem-statement-03.txt) > >Med, > >Instead of repeating the argument, please see >http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >http://www.ietf.org/mail-archive/web/sfc/current/msg00897.html >http://www.ietf.org/mail-archive/web/sfc/current/msg00900.html > >I would certainly *not* describe Section 3 as an "unbacked framework >discussion". By the way, looking at the charter for SFC, the word >/framework/i appears exactly zero instances. > >Best, > >-- Carlos. > >On Apr 2, 2014, at 1:45 AM, mohamed.boucadair@orange.com wrote: > >> Hi Darell, >> >> That text is not related to the description of the problems; it goes >beyond that. That section includes technical points that should be >discussed more in a framework document. >> >> I don't understand why that section is useful to understand the problem >space. >> >> I still object packaging a problem statement document with unbacked >framework discussion. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>> Envoy=E9 : mardi 1 avril 2014 20:44 >>> =C0 : Thomas Nadeau >>> Cc : Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>> Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: >I-D >>> Action: draft-ietf-sfc-problem-statement-03.txt) >>> >>> My opinion has not changed, the section seems useful and I see no reaso= n >it >>> should be removed. >>> >>> -Darrel >>> On Apr 1, 2014, at 7:14 AM, Thomas Nadeau >wrote: >>> >>>> >>>> This has come up before, and there seemed to be a lot of folks who >>> wanted to leave section 3 in the document, but I will let the chairs >make >>> the consensus call. >>>> >>>> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>>> >>>> --Tom >>>> >>>> >>>> On Apr 1, 2014:7:42 AM, at 7:42 AM, >>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> I raised this point to the co-authors but I prefer to raise it also i= n >>> the mailing list. >>>>> >>>>> I suggest to remove Section 3 from the draft >>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section- >3, >>> because it goes beyond the problem discussion. That section is more a >>> discussion that should be hosted in a framework document. >>>>> >>>>> Furthermore, some of the points mentioned in that section are >>> questionable such as the use of metadata and the need of control >protocols, >>> etc. Let's avoid mixing objectives and limit the scope of the PS I-D to >the >>> identification to the problems to be solved. >>>>> >>>>> Aside not, the WG charter is clear about the scope of the PS I-D: >>>>> >>>>> " >>>>> 1. Problem Statement: This document will provide a summary of the >>>>> problem space to be addressed by the SFC working group including >>>>> example high-level use cases. >>>>> " >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>>>>> drafts@ietf.org >>>>>> Envoy=E9 : mardi 1 avril 2014 12:38 >>>>>> =C0 : i-d-announce@ietf.org >>>>>> Cc : sfc@ietf.org >>>>>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Service Function Chaining Working >>> Group >>>>>> of the IETF. >>>>>> >>>>>> Title : Service Function Chaining Problem Statement >>>>>> Authors : Paul Quinn >>>>>> Thomas Nadeau >>>>>> Filename : draft-ietf-sfc-problem-statement-03.txt >>>>>> Pages : 18 >>>>>> Date : 2014-04-01 >>>>>> >>>>>> 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 instances 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-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-= 03 >>>>>> >>>>>> >>>>>> 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/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Thu Apr 3 06:24:13 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 5DD7F1A01BF for ; Thu, 3 Apr 2014 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 pC5P6qEoZs1b for ; Thu, 3 Apr 2014 06:24:08 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id E64581A01BC for ; Thu, 3 Apr 2014 06:24:07 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Thu, 3 Apr 2014 09:24:03 -0400 From: Dave Dolson To: "sfc@ietf.org" , Ron Parker Thread-Topic: [sfc] SFC encapsulation chain ID Thread-Index: AQHPQs8yf7wFx4LPHUOw5xFVMCYyJJrnY/wAgAACAACAAAL2AIAA1xuAgAC62wCAAFcSAIAKtLsAgAABtQCAAAIqgIAAA3mAgAAPD4CAAAjKAIALzJfw Date: Thu, 3 Apr 2014 13:24:02 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D4535AFF4@dfweml701-chm.china.huawei.com> <532A2700.8010304@joelhalpern.com> <53332386.2030904@joelhalpern.com> , <0BF7E0211CA62B42AE3FD4020E41609884AA082B@SEAEMBX01.olympus.F5Net.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.200.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BK0q02GcY5w-JOCiaMLPdQAbBVo Subject: Re: [sfc] SFC encapsulation chain ID 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, 03 Apr 2014 13:24:12 -0000 There is another (degenerate?) case that can be made to work. (c) any given instance of the service function only processes traffic for o= ne chain. (i.e., the forwarding rules are the same for all packets) In this case, for example, new flows can be created and the SFF knows what = to do with them. This might not be as crazy as it sounds, given the world of NFV. (d) Physical interfaces can indicate chain. Two-interface transparent proxi= es will keep track of whether packets are travelling right-to-left or left-= to-right. In this case, two chains can be supported (for one bidirectional = chain). The interface indicates to the SFF which forwarding rules to use. (e) Other existing transparent proxies can intersect a VLAN trunk and keep = track of packet context in VLAN terms. In this case, an SFF can provide a s= ervice chain per VLAN tag per physical interface. Probably many of you will feel these are obvious, but they are not represen= ted by the (a) and (b) constraints below. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Wednesday, March 26, 2014 4:45 PM To: Sumandra Majee; Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; s= fc@ietf.org Subject: Re: [sfc] SFC encapsulation chain ID Sumandra, I don't think that all service functions could be or should be made to work= in an SFC environment with no changes. In a previous airing of this issu= e, we concluded that only service functions that satisfied certain constrai= nts could be made to work in an SFC environment with no changes. In fact,= Joel H. and I had a disagreement whether it was proper to state that servi= ce functions that satisfied those constraints were "simple" service functio= ns -- I withdrew my characterization of them as such. Those constraints w= ere a) the service function must not change the key fields of the IP header= (i.e., 5-tuple) and b) must not launch separate flows (e.g., many HTTP tra= nsparent proxy implementations). Otherwise, that service function is not = a candidate to operate under SFC without change. Sure, it can and does o= perate under pre-existing ways of doing things, but that isn't the point of= our exercise. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee Sent: Wednesday, March 26, 2014 4:13 PM To: Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; sfc@ietf.org Subject: Re: [sfc] SFC encapsulation chain ID Surendra, At the risk of repeating myself, I say AGREE. However me, you and rest agreeing means zilch to the application developers= . What I am saying is that the architecture should take a stand that the e= xisting Service Function will work as is. Currently the stand is that if t= he application does not work then go Fix it. =20 Did we give this enough thought in a collective way? There are existing service chain solutions that doesn't mandate any form of= change in the existing service interface. Would it be nice to have as a go= al? Regards, Sumandra ________________________________________ From: Surendra Kumar (smkumar) [smkumar@cisco.com] Sent: Wednesday, March 26, 2014 12:19 PM To: Sumandra Majee; Joel M. Halpern; Lucy yong; sfc@ietf.org Subject: Re: [sfc] SFC encapsulation chain ID Sumandra, This seems like whether a specific SF is SFC compatible or not ? If compati= ble, how much, based on the requirement language in SFC. That is why it is all the more important to have a simple, clean & short se= rvice header - may have greater chance of adoption. Surendra. On 3/26/14 12:07 PM, "Sumandra Majee" wrote: > > >On 3/26/14, 11:59 AM, "Joel M. Halpern" wrote: > >>If the service function preserves the transport header and the serice=20 >>chaining header, then even though the packet header has been changed,=20 >>the transport and / or the SFC header will direct the packet onwards=20 >>along the intended path. Since this is needed for preserving metadata=20 >>anyway, this is our targeted mode as I understand it. Which simply=20 >>works with your SF_VO case below. > >[SM] Yes. However I am not sure if the architecture can count on the=20 >preservation part. >I as a network engineer at times often misjudged the application=20 >developer restriction and requirement. >SFC in a way would need to bridge this gap (or be aware what works and=20 >what doesn=B9t). > >Regards. > >Sumandra > >_______________________________________________ >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 nobody Thu Apr 3 07:25: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 EDE4A1A01F1 for ; Thu, 3 Apr 2014 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 e5PaB5EAIQI5 for ; Thu, 3 Apr 2014 07:25:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 613021A01E9 for ; Thu, 3 Apr 2014 07:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8164; q=dns/txt; s=iport; t=1396535136; x=1397744736; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=woLz905/++IOqLdFX3OB6gcL4/+fwyU6gHFIj581/gE=; b=bzRKMCup9vUpRtD3paG9Y178dlxJm3iAUVozwKfzh61s7QdTQ6vgerPY OPCkwnam09Pp4BpzD1f+26ZLXRQjcoQGR8erCLKMyxMIfBw2v8TGHlXX0 rdvKarWNZdZpMj7WkPVsx3Vy3x6dQBbjpObU7/PBfsV0BAMgOdVeKzx7x w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAChuPVOtJV2b/2dsb2JhbABYgwY7UQa8P4c3gR8WdIIlAQEBBAEBAWIJCwwEAgEIEQMBAgEjBAcnCxQJCAIEDgUJEodeCAXPEReOGgYBARwzAgUGhDIEiSKPOYE0kQqBcYE/gWoIFyI X-IronPort-AV: E=Sophos;i="4.97,787,1389744000"; d="scan'208";a="314955509" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2014 14:25:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s33EPZWx003337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Apr 2014 14:25:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 09:25:34 -0500 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAPxz0AAAlqtgAAFyBhgAAcO/WAABC7E6AADxc+AA== Date: Thu, 3 Apr 2014 14:25:34 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> <94C682931C08B048B7A8645303FDC9F36F547C7083@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F547C7083@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.117.115.55] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2Ixgd-CFN7avjTYyIsVloD7rmt8 Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Thu, 03 Apr 2014 14:25:45 -0000 Hi, Med, I apologize but I still do not fully understand your point. You say: =B3Let us shape a problem statement that is solution-neutral=B2, which to me seems to imply you believe the problem statement is not =B3solution-neutral=B2, and you seem to blame Section 3 for that. But Section 3 starts by saying: =B3Concretely, the SFC working group will investigate solutions that address the following elements=B2, and then goes about defining elements, not solutions. The *solutions* that will later solve the problem defined in this *problem statement* need to address the *elements* of Section 3. Like I said, it=B9s impossible to describe a problem without putting names and boundaries to what SFC is (not a solution). We might need to agree to disagree on this... Thanks, Carlos. -----Original Message----- From: Med Boucadair Date: Thursday, April 3, 2014 at 4:37 AM To: Carlos Pignataro Cc: "Darrel Lewis (darlewis)" , Tom Nadeau , "sfc@ietf.org" Subject: RE: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) >Hi Carlos, > >Thanks for pointing to these messages. > >With all due respect, only the first one you cited tries to motivate the >need for such section. But the argument you provided does not make sense >to me, since it is the role of the charter to do that... not to froze >them in an RFC.=20 > >IMHO, the group should be open to any proposal that claim to solve the >problems listed in the problem statement. > >Let us shape a problem statement that is solution-neutral. > >Cheers, >Med > >>-----Message d'origine----- >>De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>Envoy=E9 : mercredi 2 avril 2014 21:14 >>=C0 : BOUCADAIR Mohamed IMT/OLN >>Cc : Darrel Lewis (darlewis); Tom Nadeau; sfc@ietf.org >>Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: >>I-D >>Action: draft-ietf-sfc-problem-statement-03.txt) >> >>Med, >> >>Instead of repeating the argument, please see >>http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>http://www.ietf.org/mail-archive/web/sfc/current/msg00897.html >>http://www.ietf.org/mail-archive/web/sfc/current/msg00900.html >> >>I would certainly *not* describe Section 3 as an "unbacked framework >>discussion". By the way, looking at the charter for SFC, the word >>/framework/i appears exactly zero instances. >> >>Best, >> >>-- Carlos. >> >>On Apr 2, 2014, at 1:45 AM, mohamed.boucadair@orange.com wrote: >> >>> Hi Darell, >>> >>> That text is not related to the description of the problems; it goes >>beyond that. That section includes technical points that should be >>discussed more in a framework document. >>> >>> I don't understand why that section is useful to understand the problem >>space. >>> >>> I still object packaging a problem statement document with unbacked >>framework discussion. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>> Envoy=E9 : mardi 1 avril 2014 20:44 >>>> =C0 : Thomas Nadeau >>>> Cc : Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>>> Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: >>I-D >>>> Action: draft-ietf-sfc-problem-statement-03.txt) >>>> >>>> My opinion has not changed, the section seems useful and I see no >>>>reason >>it >>>> should be removed. >>>> >>>> -Darrel >>>> On Apr 1, 2014, at 7:14 AM, Thomas Nadeau >>wrote: >>>> >>>>> >>>>> This has come up before, and there seemed to be a lot of folks who >>>> wanted to leave section 3 in the document, but I will let the chairs >>make >>>> the consensus call. >>>>> >>>>> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>>>> >>>>> --Tom >>>>> >>>>> >>>>> On Apr 1, 2014:7:42 AM, at 7:42 AM, >>>> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> I raised this point to the co-authors but I prefer to raise it also >>>>>>in >>>> the mailing list. >>>>>> >>>>>> I suggest to remove Section 3 from the draft >>>>=20 >>>>http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section- >>3, >>>> because it goes beyond the problem discussion. That section is more a >>>> discussion that should be hosted in a framework document. >>>>>> >>>>>> Furthermore, some of the points mentioned in that section are >>>> questionable such as the use of metadata and the need of control >>protocols, >>>> etc. Let's avoid mixing objectives and limit the scope of the PS I-D >>>>to >>the >>>> identification to the problems to be solved. >>>>>> >>>>>> Aside not, the WG charter is clear about the scope of the PS I-D: >>>>>> >>>>>> " >>>>>> 1. Problem Statement: This document will provide a summary of the >>>>>> problem space to be addressed by the SFC working group including >>>>>> example high-level use cases. >>>>>> " >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>>>>>> drafts@ietf.org >>>>>>> Envoy=E9 : mardi 1 avril 2014 12:38 >>>>>>> =C0 : i-d-announce@ietf.org >>>>>>> Cc : sfc@ietf.org >>>>>>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Service Function Chaining Working >>>> Group >>>>>>> of the IETF. >>>>>>> >>>>>>> Title : Service Function Chaining Problem Statement >>>>>>> Authors : Paul Quinn >>>>>>> Thomas Nadeau >>>>>>> Filename : draft-ietf-sfc-problem-statement-03.txt >>>>>>> Pages : 18 >>>>>>> Date : 2014-04-01 >>>>>>> >>>>>>> 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 instances 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-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>>=20 >>>>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-= 03 >>>>>>> >>>>>>> >>>>>>> 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/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 nobody Thu Apr 3 12:22: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 6D6401A005F for ; Thu, 3 Apr 2014 12:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 T8ekwRHkogJu for ; Thu, 3 Apr 2014 12:21:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 801021A00B5 for ; Thu, 3 Apr 2014 12:21:57 -0700 (PDT) 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 BFF90008; Thu, 03 Apr 2014 19:21:52 +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; Thu, 3 Apr 2014 20:21:02 +0100 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; Thu, 3 Apr 2014 20:21:49 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Thu, 3 Apr 2014 12:21:36 -0700 From: Linda Dunbar To: "Carlos Pignataro (cpignata)" , "mohamed.boucadair@orange.com" Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAT+B8AAAlqtgAAFyBhgAAcPBwAABwKCYAADCoyAAAEiLmQ Date: Thu, 3 Apr 2014 19:21:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CEC2FE@dfweml701-chm.china.huawei.com> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> <94C682931C08B048B7A8645303FDC9F36F547C7083@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.80] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JpKbgm4NrT-JR3sieDbHIe0DTDU Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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: Thu, 03 Apr 2014 19:22:04 -0000 IMHO, the Section 3.4 "Dataplane metadata" is solution oriented. For many e= nvironment, the Metadata can be passed down by control plane. I think this = section should be simply called "metadata", with the detailed solution of = passing down metadata out of the problem statement.=20 The Section 3.3 "Service Classification" can be so easily mis-interpreted a= s for the purpose of differentiating Service types (mentioned the Section 3= .2).=20 Based on the description of the Section 3.3, the title should be "Traffic c= lassification".=20 Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Thursday, April 03, 2014 9:26 AM To: mohamed.boucadair@orange.com Cc: Darrel Lewis (darlewis); sfc@ietf.org; Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D= Action: draft-ietf-sfc-problem-statement-03.txt) Hi, Med, I apologize but I still do not fully understand your point. You say: =B3Let us shape a problem statement that is solution-neutral=B2, w= hich to me seems to imply you believe the problem statement is not =B3solut= ion-neutral=B2, and you seem to blame Section 3 for that. But Section 3 starts by saying: =B3Concretely, the SFC working group will i= nvestigate solutions that address the following elements=B2, and then goes = about defining elements, not solutions. The *solutions* that will later sol= ve the problem defined in this *problem statement* need to address the *elements* of Section 3. Like I said, it=B9s impossible to describe a probl= em without putting names and boundaries to what SFC is (not a solution). We might need to agree to disagree on this... Thanks, Carlos. -----Original Message----- From: Med Boucadair Date: Thursday, April 3, 2014 at 4:37 AM To: Carlos Pignataro Cc: "Darrel Lewis (darlewis)" , Tom Nadeau , "sfc@ietf.org" Subject: RE: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) >Hi Carlos, > >Thanks for pointing to these messages. > >With all due respect, only the first one you cited tries to motivate=20 >the need for such section. But the argument you provided does not make=20 >sense to me, since it is the role of the charter to do that... not to=20 >froze them in an RFC. > >IMHO, the group should be open to any proposal that claim to solve the=20 >problems listed in the problem statement. > >Let us shape a problem statement that is solution-neutral. > >Cheers, >Med > >>-----Message d'origine----- >>De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Envoy=E9 :=20 >>mercredi 2 avril 2014 21:14 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Darrel=20 >>Lewis (darlewis); Tom Nadeau; sfc@ietf.org Objet : Re: [sfc] Remove=20 >>Section 3 from the problem statement (was RE: >>I-D >>Action: draft-ietf-sfc-problem-statement-03.txt) >> >>Med, >> >>Instead of repeating the argument, please see=20 >>http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>http://www.ietf.org/mail-archive/web/sfc/current/msg00897.html >>http://www.ietf.org/mail-archive/web/sfc/current/msg00900.html >> >>I would certainly *not* describe Section 3 as an "unbacked framework=20 >>discussion". By the way, looking at the charter for SFC, the word=20 >>/framework/i appears exactly zero instances. >> >>Best, >> >>-- Carlos. >> >>On Apr 2, 2014, at 1:45 AM, mohamed.boucadair@orange.com wrote: >> >>> Hi Darell, >>> >>> That text is not related to the description of the problems; it goes >>beyond that. That section includes technical points that should be=20 >>discussed more in a framework document. >>> >>> I don't understand why that section is useful to understand the=20 >>> problem >>space. >>> >>> I still object packaging a problem statement document with unbacked >>framework discussion. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] Envoy=E9 :=20 >>>> mardi 1 avril 2014 20:44 =C0 : Thomas Nadeau Cc : Darrel Lewis=20 >>>> (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re:=20 >>>> [sfc] Remove Section 3 from the problem statement (was RE: >>I-D >>>> Action: draft-ietf-sfc-problem-statement-03.txt) >>>> >>>> My opinion has not changed, the section seems useful and I see no=20 >>>>reason >>it >>>> should be removed. >>>> >>>> -Darrel >>>> On Apr 1, 2014, at 7:14 AM, Thomas Nadeau >>wrote: >>>> >>>>> >>>>> This has come up before, and there seemed to be a lot of folks=20 >>>>> who >>>> wanted to leave section 3 in the document, but I will let the=20 >>>> chairs >>make >>>> the consensus call. >>>>> >>>>> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>>>> >>>>> --Tom >>>>> >>>>> >>>>> On Apr 1, 2014:7:42 AM, at 7:42 AM, >>>> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> I raised this point to the co-authors but I prefer to raise it=20 >>>>>>also in >>>> the mailing list. >>>>>> >>>>>> I suggest to remove Section 3 from the draft >>>>=20 >>>>http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#secti >>>>on- >>3, >>>> because it goes beyond the problem discussion. That section is more=20 >>>> a discussion that should be hosted in a framework document. >>>>>> >>>>>> Furthermore, some of the points mentioned in that section are >>>> questionable such as the use of metadata and the need of control >>protocols, >>>> etc. Let's avoid mixing objectives and limit the scope of the PS=20 >>>>I-D to >>the >>>> identification to the problems to be solved. >>>>>> >>>>>> Aside not, the WG charter is clear about the scope of the PS I-D: >>>>>> >>>>>> " >>>>>> 1. Problem Statement: This document will provide a summary of the=20 >>>>>> problem space to be addressed by the SFC working group including=20 >>>>>> example high-level use cases. >>>>>> " >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet-=20 >>>>>>> drafts@ietf.org Envoy=E9 : mardi 1 avril 2014 12:38 =C0 :=20 >>>>>>> i-d-announce@ietf.org Cc : sfc@ietf.org Objet : [sfc] I-D=20 >>>>>>> Action: draft-ietf-sfc-problem-statement-03.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>> Internet-Drafts directories. >>>>>>> This draft is a work item of the Service Function Chaining=20 >>>>>>> Working >>>> Group >>>>>>> of the IETF. >>>>>>> >>>>>>> Title : Service Function Chaining Problem Statement >>>>>>> Authors : Paul Quinn >>>>>>> Thomas Nadeau >>>>>>> Filename : draft-ietf-sfc-problem-statement-03.txt >>>>>>> Pages : 18 >>>>>>> Date : 2014-04-01 >>>>>>> >>>>>>> Abstract: >>>>>>> This document provides an overview of the issues associated with=20 >>>>>>>the deployment of service functions (such as firewalls, load=20 >>>>>>>balancers) in large-scale environments. The term service=20 >>>>>>>function chaining is used to describe the definition and=20 >>>>>>>instantiation of an ordered set of instances of such service=20 >>>>>>>functions, and the subsequent "steering" >>>>>>> of traffic flows through those service functions. >>>>>>> >>>>>>> The set of enabled service function chains reflect operator=20 >>>>>>> service offerings and is designed in conjunction with=20 >>>>>>> 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-statemen >>>>>>> t/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>>=20 >>>>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement >>>>>>>-03 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time=20 >>>>>>>of submission until the htmlized version and diff are available=20 >>>>>>>at tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 nobody Thu Apr 3 15:30: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 2DC731A031D for ; Thu, 3 Apr 2014 15:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 K5EJbjid7tXF for ; Thu, 3 Apr 2014 15:30:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 076D51A0316 for ; Thu, 3 Apr 2014 15:30:29 -0700 (PDT) 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 BFF97973; Thu, 03 Apr 2014 22:30:24 +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; Thu, 3 Apr 2014 23:29:22 +0100 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Apr 2014 23:30:20 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML702-CHM.china.huawei.com ([169.254.4.52]) with mapi id 14.03.0158.001; Thu, 3 Apr 2014 15:30:13 -0700 From: Cathy Zhang To: "mikebianc@aol.com" Thread-Topic: [sfc] SFC encapsulation chain ID Thread-Index: AQHPQs83oQRF4Vi4nkyRETtZ1eglQZrndL8A//+MpgCAACHtQIABWV6AgAC1AgCAABnpAIAAGK+AgAe3owCAACKigIACprkAgAANyICAAAO3gIAAAVOAgAAEeoCAAAM3gIAAAvaAgAABZoCAAAD6gP//pflwgAB+SAD//4v/IAFGexUAAFKqPFA= Date: Thu, 3 Apr 2014 22:30:13 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6E7B88FB165@MAILR002.mail.lan> <53308576.6030107@acm.org> <5330A283.6050007@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361692@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332E76D.6010809@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E013617DD@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332EBA7.3000100@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361830@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E013619D0@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361A1A@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361B80@MISOUT7MSGUSR9I.ITServices.sbc.com> <1516725807.33000.1396392616203.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1516725807.33000.1396392616203.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.212.145.108] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F2752ESJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/flPtvaH0d71in0WKchbThdoOMfY Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC encapsulation chain ID 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, 03 Apr 2014 22:30:36 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F2752ESJCEML703CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBjb21lIGJhY2sgZnJvbSBteSBQVE8uIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpUaGFua3Ms DQpDYXRoeQ0KDQpGcm9tOiBtaWtlYmlhbmNAYW9sLmNvbSBbbWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tXQ0KU2VudDogVHVlc2RheSwgQXByaWwgMDEsIDIwMTQgMzo1MCBQTQ0KVG86IENhdGh5IFpo YW5nDQpDYzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIGVuY2Fwc3VsYXRp b24gY2hhaW4gSUQNCg0KSW4gdGhpcyBjYXNlLCBpdCBpcyBzdGlsbCBhIGhvcC4gIFRoZSBMQiBW TSBzdGlsbCBoYXMgdG8gcHJvY2VzcyAoYW5kICJiYWxhbmNlIikgdGhlIHBhY2tldHMsIHdoaWNo IGluY3VycyBhIGxhcmdlciBwZW5hbHR5IHRoYW4gdGhlIDUwMG5zIChvciBzbykgb2YgYSBwaHlz aWNhbCBuZXR3b3JrIGhvcC4gIEFkZGl0aW9uYWxseSwgdGhlICJob3AiIHRoYXQgeW91IHNheSBp cyBtaXRpZ2F0ZWQgaXMgb25seSBtaXRpZ2F0ZWQgaWYgeW91IGNvbG9jYXRlIGFsbCBvZiB0aGUg Vk1zIGJlaGluZCBhIExCIGluc3RhbmNlIHdpdGggdGhlIExCIGl0c2VsZiwgd2hpY2ggaXMgbm90 IHZlcnkgZWxhc3RpYywgcmVxdWlyaW5nIG9uZSB0byBjcmVhdGUgbXVsdGlwbGUgaW5zdGFuY2Vz IG9mIExCcyBmb3IgdGhlIHNhbWUgU0YsIHdoaWNoIHJlcXVpcmVzIGVpdGhlciBoYXZpbmcgaW5z dGFuY2VzIGNob3NlbiBieSBhbiBTRkMgY2xhc3NpZmllciAod2hpY2ggeW91IGFyZSB0cnlpbmcg dG8gYXZvaWQpIG9yIGludHJvZHVjaW5nIGEgTEIgaW4gYSBkaWZmZXJlbnQgbG9jYXRpb24gdG8g YmFsYW5jZSBiZXR3ZWVuIG11bHRpcGxlIGxvY2FsIExCcyAoZnJvbnRpbmcgdGhlIFNGIFZNIGlu c3RhbmNlcyksIHdoaWNoIHNpbXBseSByZS1pbnRyb2R1Y2VzIHRoZSBob3BzIHRoYXQgeW91IHdl cmUgdHJ5aW5nIHRvIG1pdGlnYXRlIGluIHRoZSBmaXJzdCBwbGFjZS4gIEkgc3VwcG9zZSB5b3Ug Y291bGQgaW1wbGVtZW50IHRoaXMgaW4gc3VjaCBhIHdheSB0aGF0IHlvdSBoYWQgYSBMQiBpbiBm cm9udCBvZiB5b3VyIFNGQyBDbGFzc2lmaWVyLCBidXQgSSdkIGhhdmUgdG8gd3JhcCBteSBoZWFk IGFyb3VuZCB0aGF0IHNvbWUgbW9yZSB0byBzZWUgaWYgaXQgZXZlbiBtYWtlcyBzZW5zZS4gIEVp dGhlciB3YXksIEkgZG9uJ3QgdGhpbmsgdGhpcyBzb2x2ZXMgd2hhdCB5b3UgdGhpbmsgaXQgc29s dmVzLg0KDQpDYXRoeT4gSXQgZGVwZW5kcyBvbiB3aGF0IGlzIG1lYW50IGJ5IOKAnGEgaG9w4oCd LiBUaGUgc2VtYW50aWNzIG9mIHRoZSDigJxzdGlsbCBhIGhvcOKAnSBpcyBkaWZmZXJlbnQgZnJv bSB0aGUgcGh5c2ljYWwgbmV0d29yayBob3Agd2hpY2ggd2FzIG1lYW50IGluIG15IHByZXZpb3Vz IHJlcGx5Lg0KQlRXLCBuZXR3b3JrIGhvcCBsYXRlbmN5IGNvdWxkIGJlIGxhcmdlciB0aGFuIDUw MG5zIGFuZCB3b3JzZSB0aGFuIGxvY2FsIHByb2Nlc3NpbmcgbGF0ZW5jeSBpZiB0aGUgbmV0d29y ayBoYXMgY29uZ2VzdGlvbi4NClllcywgdGhlIOKAnGhvcOKAnSBpcyBvbmx5IG1pdGlnYXRlZCBp ZiB0aGUgVk0gaW5zdGFuY2UgY2x1c3RlciBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgc2Vydmlj ZSBmdW5jdGlvbiBpcyBub3QgbGFyZ2UgYW5kIGlzIGNvbGxvY2F0ZWQgd2l0aCB0aGUgTEIuDQpG b3Igc2NlbmFyaW9zIHRoYXQgVk0gaW5zdGFuY2VzIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ug ZnVuY3Rpb24gYXJlIG9mIGxhcmdlIHNpemUgYW5kIHdpZGVseSBkaXN0cmlidXRlZCwgbXVsdGlw bGUgTEJzIG1pZ2h0IGJlIG5lZWRlZCB0byBmcm9udC1lbmQgdGhlIFZNcyBhbmQNCnRoZSBjbGFz c2lmaWVyIG5lZWRzIHRvIGJlIGF3YXJlIG9mIHRoZXNlIExCcy4gIE9yIHNvbWUgb3RoZXIgYmV0 dGVyIG1lY2hhbmlzbSBuZWVkcyB0byBiZSBzb3J0ZWQgb3V0IHRvIHNvbHZlIHRoZSBzY2FsYWJp bGl0eSBpc3N1ZSAodG9vIG1hbnkgc2VydmljZSBwYXRocyB3aXRoIHBlcm11dGF0aW9ucyBvZiBz ZXJ2aWNlIGluc3RhbmNlcykuDQpZZXMsIHdlIGFyZSBpbiBzeW5jIHRoYXQgZnJvbnQgZW5kaW5n IFZNIGNsdXN0ZXIgd2l0aCBhIExCIGluY3VycyBleHRyYSBwcm9jZXNzaW5nIGFuZCBsYXRlbmN5 Lg0KQXMgZGlzY3Vzc2VkIGluIHRoaXMgZW1haWwgdGhyZWFkIGJlZm9yZSwgZXZlcnl0aGluZyBo YXMgYSBzY2FsZSBsaW1pdCBhbmQgc2NhbGFiaWxpdHkgZW5oYW5jZW1lbnQgbWVjaGFuaXNtcyB1 c3VhbGx5IGluY3VyIHNvbWUgY29zdCBhbmQgYXBwbGljYXRpb24gbGltaXRhdGlvbi4NCg0KV2h5 IGNhbid0IHdlIHNpbXBseSBzYXkgdGhhdCB0aGUgU0ZDIGNsYXNzaWZpZXIgY2hvb3NlcyB0aGUg U0ZDIFBhdGggKHNwZWNpZmljIFNGIGluc3RhbmNlcykgYW5kIGFzIGEgbWF0dGVyIG9mIGltcGxl bWVudGF0aW9uLCBpZiB5b3Ugd291bGQgbGlrZSwgeW91IG1heSBjb25zdHJ1Y3QgeW91ciBjaGFp biB0byBiZSBhIGNoYWluIG9mIFNGIExCcywgZWFjaCB3aXRoIGEgc2luZ2xlIGluc3RhbmNlPyAg VGhhdCB3b3VsZCBhbGxvdyB5b3UgdG8gc2NhbGUgYXQgdGhlIGNvc3Qgb2YgdGhlIGluY3JlbWVu dGFsIGxhdGVuY3kgdGhhdCBpbmhlcmVudGx5IGNvbWVzIHdpdGggc2NhbGluZywgYnV0IGFsc28g YWxsb3cgYSBzbWFsbGVyIGltcGxlbWVudGF0aW9uIHRvIGZvcmdvIHRoZSBMQnMgYW5kIHBlcmZv cm0gdGhlIGRpc3RyaWJ1dGlvbiBmdW5jdGlvbiBhdCB0aGUgQ2xhc3NpZmllci4NCg0KQ2F0aHk+ IFN1cmUsIEkgYW0gZmluZSB3aXRoIHRoZSBzYXlpbmcgZXhjZXB0IHRoYXQgdGhlIGNoYWluIGNh biBiZSBhIGNvbWJpbmF0aW9uIG9mIOKAnFNGIExCcyBhbmQgc2VydmljZSBpbnN0YW5jZXPigJ0g aW5zdGVhZCBvZiDigJxhIGNoYWluIG9mIFNGIExCc+KAnS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IENhdGh5LkguWmhhbmdAaHVhd2VpLmNvbTxDYXRoeS5ILlpo YW5nQGh1YXdlaS5jb20+DQpUbzogTkFQSUVSQUxBLCBNQVJJQSBIPG1uMTkyMUBhdHQuY29tPixS b24gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+LEpvZWwgSGFscGVybiBE aXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+LEpvZWwgTS4gSGFscGVybjxqbWhAam9l bGhhbHBlcm4uY29tPixFcmlrIE5vcmRtYXJrPG5vcmRtYXJrQGFjbS5vcmc+LEtldmluIEogTWE8 a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4sRGF2ZSBEb2xzb248ZGRvbHNvbkBzYW5kdmluZS5j b20+LFN1bWFuZHJhIE1hamVlPFMuTWFqZWVARjUuY29tPg0KY2M6IHNmY0BpZXRmLm9yZzxzZmNA aWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0DQpTdWJqZWN0OiBSZTog W3NmY10gU0ZDIGVuY2Fwc3VsYXRpb24gY2hhaW4gSUQNCg0KSG9wcyBjYW4gYmUgbWl0aWdhdGVk IGJ5IHJ1bm5pbmcgdGhlIExCIGluIHRoZSBzYW1lIGxvY2F0aW9uIGFzIHRob3NlIFNGIFZNcw0K VGhlIGNvbm5lY3Rpb24gZnJvbSBMQiB0byB0aG9zZSBTRiBWTXMgaXMgbG9jYWwsIG5vdCBob3Bz Lg0KDQpDYXRoeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQoNCkZyb206IE5BUElF UkFMQSwgTUFSSUEgSCBbbWFpbHRvOm1uMTkyMUBhdHQuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBN YXJjaCAyNiwgMjAxNCAxMDo1NyBBTQ0KVG86IENhdGh5IFpoYW5nOyBSb24gUGFya2VyOyBKb2Vs IEhhbHBlcm4gRGlyZWN0OyBKb2VsIE0uIEhhbHBlcm47IEVyaWsgTm9yZG1hcms7IEtldmluIEog TWE7IERhdmUgRG9sc29uOyBTdW1hbmRyYSBNYWplZQ0KQ2M6IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogUkU6IFtzZmNdIFNGQyBlbmNhcHN1bGF0aW9uIGNoYWluIElEDQoNCj4NCj4gSWYgY2FzZSAx IHBvc2VzIGEgc2NhbGFiaWxpdHkgcHJvYmxlbSAoZWcuIHRoZXJlIGFyZSBodW5kcmVkcyBvZiBW TXMNCj4gZm9yIGEgc2VydmljZSBmdW5jdGlvbiksIHRoZSBzY2FsYWJpbGl0eSBpc3N1ZSBjYW4g YmUgc29sdmVkIGJ5DQo+IHRyYW5zZm9ybWluZyBjYXNlIDEgaW50byBjYXNlIDINCj4gdGhyb3Vn aCBwbGFjaW5nIGEgbG9jYWwgTEIgYmVmb3JlIHRoZXNlIFZNcyBhbmQgb25seSB0aGUgTEIgaXMg dmlld2VkDQo+IGluIHRoZSBjaGFpbi4NCg0KSW50cm9kdWNpbmcgYWRkaXRpb25hbCBob3AgaXMg YSBzZXJ2aWNlIGNoYWluIHRyYW5zbGF0ZXMgdG8gZGVsYXkgYW5kIGNvc3QuIEltYWdpbmUgYSA1 IGhvcCBjaGFpbiwgZWFjaCBmcm9udGVkIHdpdGggYW4gZXh0ZXJuYWwgTEIgU0YuIDUtaG9wIGNo YWluIGJlY29tZXMgMTAtaG9wIGNoYWluLg0KSW4gZmFjdCwgaWYgdGhlIExCIGlzIGEgdmlydHVh bCBhcHBsaWFuY2UgaXQgbWlnaHQgaGF2ZSBzaW1pbGFyIHNjYWxhYmlsaXR5IGlzc3VlIGFzIHRo ZSBvcmlnaW5hbCBTRi4NCg0KPiBJbiBzb21lIG90aGVyIGRlcGxveW1lbnQgc2NlbmFyaW8sIGNh c2UgMSBtaWdodCBub3QgcG9zZQ0KPiBhIHNjYWxhYmlsaXR5IGlzc3VlLCBhbmQNCj4gdGh1cyBz b2x1dGlvbi9hcmNoaXRlY3R1cmUgd2lzZSwgd2Ugc2hvdWxkIG5vdCBleGNsdWRlIGNhc2UgMS4g VG8gcHV0DQo+IGl0IGFub3RoZXIgd2F5LCBjYXNlIDEgaXMgb25seSB1c2FibGUgaW4gc21hbGwt c2NhbGUgc2NlbmFyaW8uDQo+DQo+IENhdGh5DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTkFQSUVSQUxBLCBNQVJJQSBIDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjYsIDIwMTQg ODo0OCBBTQ0KPiBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgSm9lbCBNLiBI YWxwZXJuOyBFcmlrIE5vcmRtYXJrOw0KPiBLZXZpbiBKIE1hOyBEYXZlIERvbHNvbjsgU3VtYW5k cmEgTWFqZWUNCj4gQ2M6IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gU0ZDIGVu Y2Fwc3VsYXRpb24gY2hhaW4gSUQNCj4NCj4gUm9uLA0KPg0KPiBJIHdvdWxkIGNvbnNpZGVyIGEg c29sdXRpb24gd2hpY2ggc2NhbGVzIG9ubHkgd2l0aCBhc3N1bXB0aW9ucyAyLiBhbmQNCj4gMy4g KGNsdXN0ZXJzIHdpdGggaW50ZXJuYWwgTEIpIGFzIGxpbWl0ZWQuDQo+DQo+IE1hcmlhDQo+DQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBSb24gUGFya2VyIFttYWls dG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXks IE1hcmNoIDI2LCAyMDE0IDExOjQ0IEFNDQo+ID4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9l bCBIYWxwZXJuIERpcmVjdDsgSm9lbCBNLiBIYWxwZXJuOyBFcmlrDQo+ID4gTm9yZG1hcms7IEtl dmluIEogTWE7IERhdmUgRG9sc29uOyBTdW1hbmRyYSBNYWplZQ0KPiA+IENjOiBzZmNAaWV0Zi5v cmcNCj4gPiBTdWJqZWN0OiBSRTogW3NmY10gU0ZDIGVuY2Fwc3VsYXRpb24gY2hhaW4gSUQNCj4g Pg0KPiA+IE1hcmlhLA0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGNhc2UgMS4gd2ls bCBvbmx5IHByYWN0aWNhbGx5IHNjYWxlIHVwIHRvIHNvbWUNCj4gPiBwb2ludC4gICAgUGVyaGFw cywgYXMgYSBzZXJ2aWNlIHByb3ZpZGVyLCB5b3UnZCBjaG9vc2UgdG8gYXZvaWQgdGhlDQo+ID4g d2hvbGUgcHJvYmxlbSBhbmQgb25seSBkZXBsb3kgc2VydmljZSBmdW5jdGlvbnMgYWxvbmcgdGhl IGxpbmVzIG9mDQo+IGNhc2UNCj4gPiAyIG9yIGNhc2UgMy4gICAgQnV0LCB0aGF0IGRvZXNuJ3Qg aW52YWxpZGF0ZSB0aGUgdXRpbGl0eSBvZiBjYXNlIDENCj4gZm9yDQo+ID4gc29tZSBvdGhlciBu ZXR3b3JrIHdpdGggc29tZSBvdGhlciByZXF1aXJlbWVudHMgYW5kIGNvbnN0cmFpbnRzLg0KPiA+ DQo+ID4gICAgUm9uDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogTkFQSUVSQUxBLCBNQVJJQSBIIFttYWlsdG86bW4xOTIxQGF0dC5jb21dDQo+ID4g U2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNiwgMjAxNCAxMTozOSBBTQ0KPiA+IFRvOiBSb24gUGFy a2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBKb2VsIE0uIEhhbHBlcm47IEVyaWsgTm9yZG1hcms7 DQo+ID4gS2V2aW4gSiBNYTsgRGF2ZSBEb2xzb247IFN1bWFuZHJhIE1hamVlDQo+ID4gQ2M6IHNm Y0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTRkMgZW5jYXBzdWxhdGlvbiBjaGFp biBJRA0KPiA+DQo+ID4gPg0KPiA+ID4gMS4gQSBzZXJ2aWNlIGZ1bmN0aW9uIGlzIHJlYWxpemVk IGJ5IG11bHRpcGxlIFZNJ3Mgd2hlcmUgZWFjaCBWTQ0KPiBoYXMNCj4gPiA+IGl0cyBvd24gSVAg YWRkcmVzcy4gICBJbiB0aGlzIGNhc2UgdGhlIGNsYXNzaWZpZXIvUERQIHNlZXMgZWFjaCBWTQ0K PiBhcw0KPiA+IGENCj4gPiA+IHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UuDQo+ID4gPg0KPiA+ DQo+ID4gSSBkb24ndCB0aGluayB0aGlzIHdpbGwgc2NhbGUuIEl0IHdhcyBwb2ludGVkIG91dCB0 aGF0IHRoZSBudW1iZXIgb2YNCj4gPiBzZXJ2aWNlIHBhdGhzIGdyb3dzIGV4cG9uZW50aWFsbHku DQo+ID4NCj4gPg0KPiA+ID4gMi4gQSBzZXJ2aWNlIGZ1bmN0aW9uLCBhcyBhYm92ZSwgYnV0IHNv bWUgc3Vic2V0IG9mIFZNJ3MgaXMgZnJvbnQtDQo+ID4gZW5kZWQNCj4gPiA+IGJ5IGEgbG9hZCBi YWxhbmNlci4gICBUaGVyZSBhcmUgbXVsdGlwbGUgc3VjaCBzdWJzZXRzIGFuZCB0aGVyZWZvcmUN Cj4gPiA+IG11bHRpcGxlIGxvYWQgYmFsYW5jZXJzLiAgIEVhY2ggbG9hZCBiYWxhbmNlciBoYXMg aXRzIG93biBJUA0KPiBhZGRyZXNzDQo+ID4gPiBhbmQgaGlkZXMgdGhlIFZNIElQIGFkZHJlc3Nl cyBiZWhpbmQgaXQuICAgSW4gdGhpcyBjYXNlLCB0aGUNCj4gPiA+IGNsYXNzaWZpZXIvUERQIHNl ZXMgZWFjaCBsb2FkIGJhbGFuY2VyIGFzIGEgc2VydmljZSBmdW5jdGlvbg0KPiA+IGluc3RhbmNl Lg0KPiA+DQo+ID4gTm8gaXNzdWUgaGVyZS4NCj4gPg0KPiA+ID4gMy4gQSBzZXJ2aWNlIGZ1bmN0 aW9uIGlzIHJlYWxpemVkIGJ5IGEgc2V0IG9mIFZNJ3MgdGhhdCBwZXJmb3JtDQo+ID4gPiBpbnRl cm5hbCBsb2FkIGJhbGFuY2luZy4gICBUaGUgc2V0IG9mIFZNJ3MgcHJlc2VudHMgYSBzaW5nbGUg SVANCj4gPiBhZGRyZXNzDQo+ID4gPiB0byB0aGUgb3V0c2lkZSB0byBoaWRlIHRoZSBJUCBhZGRy ZXNzZXMgb2YgdGhlIGluZGl2aWR1YWwgVk1zLg0KPiBUaGUNCj4gPiA+IG5ldHdvcmsgaGFzIG11 bHRpcGxlIHN1Y2ggY2x1c3RlcnMuICAgVGhlIGNsYXNzaWZpZXIvUERQIHNlZXMgZWFjaA0KPiA+ ID4gY2x1c3RlciBhcyBhIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UuDQo+ID4NCj4gPg0KPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG cm9tOiBOQVBJRVJBTEEsIE1BUklBIEggW21haWx0bzptbjE5MjFAYXR0LmNvbV0NCj4gPiA+IFNl bnQ6IFdlZG5lc2RheSwgTWFyY2ggMjYsIDIwMTQgMTE6MTcgQU0NCj4gPiA+IFRvOiBKb2VsIEhh bHBlcm4gRGlyZWN0OyBKb2VsIE0uIEhhbHBlcm47IEVyaWsgTm9yZG1hcms7IEtldmluIEoNCj4g TWE7DQo+ID4gPiBSb24gUGFya2VyOyBEYXZlIERvbHNvbjsgU3VtYW5kcmEgTWFqZWUNCj4gPiA+ IENjOiBzZmNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTRkMgZW5jYXBzdWxh dGlvbiBjaGFpbiBJRA0KPiA+ID4NCj4gPiA+IEpvZWwsDQo+ID4gPg0KPiA+ID4gPiBUaGUgcG9p bnQgb2YgdGhlIGRpc3RpbmN0aW9uIHdhcyBiZXR3ZWVuIG9uIHRoZSBvbmUgaGFuZCBsb2FkDQo+ ID4gPiA+IGJhbGFuY2luZyBhcyBwYXJ0IG9mIHRoZSBjaGFpbiBmb3IgdGhlIHB1cnBvc2Ugb2Yg c2VsZWN0aW5nIGFuDQo+ID4gPiA+IGluc3RhbmNlIG9mIHRoZSBhY3R1YWxseSBhZGRyZXNzZWQg ZGVzdGluYXRpb24gKGkuZS4gdGhlIGxvYWQNCj4gPiA+IGJhbGFuY2VyDQo+ID4gPiA+IGlzIHZp c2libGUgdG8gdGhlIHRlbmFudCBhbmQgaXMgdGhlcmUgZm9yIHRoZSBwdXJwb3NlIHRoZSB0ZW5h bnQNCj4gPiA+ID4gcmVxdWVzdDsgYW5kIG9uIHRoZSBvdGhlciBoYW5kIGEgbG9hZCBiYWxhbmNl ciB3aGljaCBpcyBrbm93biB0bw0KPiA+IHRoZQ0KPiA+ID4gPiBzZXJ2aWNlIGNoYWluaW5nIGlu ZnJhc3RydWN0dXJlLCBidXQgd2hvc2UgcHVycG9zZSB0byBiYWxhbmNlDQo+ID4gYWNyb3NzDQo+ ID4gPiA+IGlzbnRhbmNlcyBvZiBzZXJ2aWNlcyB3aG9zZSBtdWx0aXBsaWNpdHkgaXMgbm90IG9m IGNvbmNlcm4gdG8gdGhlDQo+ID4gPiA+IHRlbmFudCwgb25seSB0aGUgZnVuY3Rpb25hbGl0eS4N Cj4gPiA+ID4NCj4gPiA+ID4gUHV0IGRpZmZlcmVudGx5LCBpdCBpcyBiZXR3ZWVuIGxvYWQgYmFs YW5jaW5nIGFzIGFuIGV4cGxpY2l0DQo+ID4gc2VydmljZQ0KPiA+ID4gPiBhbmQgbG9hZCBiYWxh bmNpbmcgdG8gZW5hYmxlIHNvbWUgc2VydmljZSB3aXRoaW4gdGhlIHNlcnZpY2UNCj4gPiA+IGNo YWluaW5nLg0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGFua3MgZm9yIGNsYXJpZmlj YXRpb24uDQo+ID4gPiBNeSBjb25jZXJuIGlzIGFib3V0IHRoZSBsYXR0ZXIsIGkuZS4sIFNGQyBz b2x1dGlvbiBtdXN0IHN1cHBvcnQNCj4gbG9hZA0KPiA+ID4gYmFsYW5jaW5nIHRvIG11bHRpcGxl IHNlcnZpY2UgaW5zdGFudGlhdGlvbnMgKGUuZy4sIFZNcykgb2YgYQ0KPiBzaW5nbGUNCj4gPiA+ IHNlcnZpY2UgYXQgdGhlIGludGVybWVkaWF0ZSBzZXJ2aWNlIGhvcHMuIEluIGZhY3QsIHdlIG5l ZWQgdGhlDQo+IGxhdHRlcg0KPiA+ID4gdG8gc3VwcG9ydCB0aGUgZm9ybWVyLi4NCj4gPiA+DQo+ ID4gPiBNYXJpYQ0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT24gMy8yNi8xNCwgMTA6NTYgQU0s IE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+PiAxKSBnaXZl biB0aGUgcmFuZ2Ugb2YgbG9hZCBiYWxhbmNpbmcgYmVoYXZpb3JzLCBzdXBwcnRpbmcNCj4gPiA+ ID4gPj4gZXhwbGljaXQNCj4gPiA+ID4gbG9hZA0KPiA+ID4gPiA+PiBiYWxhbmNlcnMgaW4gdGhl IHNlcnZpY2UgY2hhaW5pbmcgKGFzIGRpc3RpbmN0IGZyb20gc3VwcG9ydGluZw0KPiA+ID4gbG9h ZA0KPiA+ID4gPiA+PiBiYWxhbmNlcnMgZm9yIGVuZCB1c2VycyksIGlzIHNpZ25pZmljYW50bHkg Y29tcGxpY2F0ZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3Rh bmQgdGhpcyBwb2ludC4gQ291bGQgeW91IGV4cGxhaW4gd2hhdA0KPiB5b3UNCj4gPiA+ID4gbWVh biBieSAiZXhwbGljaXQiIGxvYWQgYmFsYW5jZXIgdnMuIGxvYWQgYmFsYW5jZXIgImZvciB0aGUg ZW5kDQo+ID4gPiB1c2VycyI/DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_A2C96F6779E6A041BC7023CC207FC99418F2752ESJCEML703CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SnVzdCBjb21lIGJhY2sgZnJvbSBteSBQVE8uIFBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYXRoeTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g bWlrZWJpYW5jQGFvbC5jb20gW21haWx0bzptaWtlYmlhbmNAYW9sLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAwMSwgMjAxNCAzOjUwIFBNPGJyPg0KPGI+VG86PC9iPiBD YXRoeSBaaGFuZzxicj4NCjxiPkNjOjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbc2ZjXSBTRkMgZW5jYXBzdWxhdGlvbiBjaGFpbiBJRDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SW4gdGhpcyBjYXNlLCBpdCBpcyBzdGlsbCBhIGhvcC4gJm5ic3A7VGhlIExCIFZNIHN0aWxsIGhh cyB0byBwcm9jZXNzIChhbmQgJnF1b3Q7YmFsYW5jZSZxdW90OykgdGhlIHBhY2tldHMsIHdoaWNo IGluY3VycyBhIGxhcmdlciBwZW5hbHR5IHRoYW4gdGhlIDUwMG5zIChvciBzbykgb2YgYSBwaHlz aWNhbCBuZXR3b3JrIGhvcC4NCiAmbmJzcDtBZGRpdGlvbmFsbHksIHRoZSAmcXVvdDtob3AmcXVv dDsgdGhhdCB5b3Ugc2F5IGlzIG1pdGlnYXRlZCBpcyBvbmx5IG1pdGlnYXRlZCBpZiB5b3UgY29s b2NhdGUgYWxsIG9mIHRoZSBWTXMgYmVoaW5kIGEgTEIgaW5zdGFuY2Ugd2l0aCB0aGUgTEIgaXRz ZWxmLCB3aGljaCBpcyBub3QgdmVyeSBlbGFzdGljLCByZXF1aXJpbmcgb25lIHRvIGNyZWF0ZSBt dWx0aXBsZSBpbnN0YW5jZXMgb2YgTEJzIGZvciB0aGUgc2FtZSBTRiwgd2hpY2ggcmVxdWlyZXMg ZWl0aGVyDQogaGF2aW5nIGluc3RhbmNlcyBjaG9zZW4gYnkgYW4gU0ZDIGNsYXNzaWZpZXIgKHdo aWNoIHlvdSBhcmUgdHJ5aW5nIHRvIGF2b2lkKSBvciBpbnRyb2R1Y2luZyBhIExCIGluIGEgZGlm ZmVyZW50IGxvY2F0aW9uIHRvIGJhbGFuY2UgYmV0d2VlbiBtdWx0aXBsZSBsb2NhbCBMQnMgKGZy b250aW5nIHRoZSBTRiBWTSBpbnN0YW5jZXMpLCB3aGljaCBzaW1wbHkgcmUtaW50cm9kdWNlcyB0 aGUgaG9wcyB0aGF0IHlvdSB3ZXJlIHRyeWluZyB0byBtaXRpZ2F0ZQ0KIGluIHRoZSBmaXJzdCBw bGFjZS4gJm5ic3A7SSBzdXBwb3NlIHlvdSBjb3VsZCBpbXBsZW1lbnQgdGhpcyBpbiBzdWNoIGEg d2F5IHRoYXQgeW91IGhhZCBhIExCIGluIGZyb250IG9mIHlvdXIgU0ZDIENsYXNzaWZpZXIsIGJ1 dCBJJ2QgaGF2ZSB0byB3cmFwIG15IGhlYWQgYXJvdW5kIHRoYXQgc29tZSBtb3JlIHRvIHNlZSBp ZiBpdCBldmVuIG1ha2VzIHNlbnNlLiAmbmJzcDtFaXRoZXIgd2F5LCBJIGRvbid0IHRoaW5rIHRo aXMgc29sdmVzIHdoYXQgeW91IHRoaW5rDQogaXQgc29sdmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2F0aHkmZ3Q7IEl0IGRlcGVuZHMgb24g d2hhdCBpcyBtZWFudCBieSDigJxhIGhvcOKAnS4gVGhlIHNlbWFudGljcyBvZiB0aGUg4oCcc3Rp bGwgYSBob3DigJ0gaXMgZGlmZmVyZW50IGZyb20gdGhlIHBoeXNpY2FsIG5ldHdvcmsgaG9wIHdo aWNoIHdhcyBtZWFudCBpbiBteSBwcmV2aW91cyByZXBseS4gJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkJUVywgbmV0d29yayBob3AgbGF0ZW5jeSBjb3VsZCBiZSBsYXJnZXIgdGhhbiA1MDBucyBhbmQg d29yc2UgdGhhbiBsb2NhbCBwcm9jZXNzaW5nIGxhdGVuY3kgaWYgdGhlIG5ldHdvcmsgaGFzIGNv bmdlc3Rpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WWVzLCB0aGUg4oCcaG9w4oCdIGlzIG9ubHkgbWl0 aWdhdGVkIGlmIHRoZSBWTSBpbnN0YW5jZSBjbHVzdGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2Ft ZSBzZXJ2aWNlIGZ1bmN0aW9uIGlzIG5vdCBsYXJnZSBhbmQgaXMgY29sbG9jYXRlZCB3aXRoIHRo ZSBMQi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gb3Igc2NlbmFyaW9zIHRoYXQgVk0gaW5zdGFuY2VzIGFz c29jaWF0ZWQgd2l0aCBhIHNlcnZpY2UgZnVuY3Rpb24gYXJlIG9mIGxhcmdlIHNpemUgYW5kIHdp ZGVseSBkaXN0cmlidXRlZCwgbXVsdGlwbGUgTEJzIG1pZ2h0IGJlIG5lZWRlZCB0byBmcm9udC1l bmQgdGhlIFZNcyBhbmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj50aGUgY2xhc3NpZmllciBuZWVkcyB0byBi ZSBhd2FyZSBvZiB0aGVzZSBMQnMuICZuYnNwO09yIHNvbWUgb3RoZXIgYmV0dGVyIG1lY2hhbmlz bSBuZWVkcyB0byBiZSBzb3J0ZWQgb3V0IHRvIHNvbHZlIHRoZSBzY2FsYWJpbGl0eSBpc3N1ZSAo dG9vIG1hbnkgc2VydmljZSBwYXRocyB3aXRoIHBlcm11dGF0aW9ucyBvZiBzZXJ2aWNlIGluc3Rh bmNlcykuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WWVzLCB3ZSBhcmUgaW4gc3luYyB0aGF0IGZyb250IGVu ZGluZyBWTSBjbHVzdGVyIHdpdGggYSBMQiBpbmN1cnMgZXh0cmEgcHJvY2Vzc2luZyBhbmQgbGF0 ZW5jeS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzIGRpc2N1c3NlZCBpbiB0aGlzIGVtYWlsIHRo cmVhZCBiZWZvcmUsIGV2ZXJ5dGhpbmcgaGFzIGEgc2NhbGUgbGltaXQgYW5kIHNjYWxhYmlsaXR5 IGVuaGFuY2VtZW50IG1lY2hhbmlzbXMgdXN1YWxseSBpbmN1ciBzb21lIGNvc3QgYW5kIGFwcGxp Y2F0aW9uIGxpbWl0YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PldoeSBjYW4ndCB3ZSBzaW1wbHkgc2F5IHRoYXQgdGhlIFNGQyBjbGFzc2lmaWVyIGNob29zZXMg dGhlIFNGQyBQYXRoIChzcGVjaWZpYyBTRiBpbnN0YW5jZXMpIGFuZCBhcyBhIG1hdHRlciBvZiBp bXBsZW1lbnRhdGlvbiwgaWYgeW91IHdvdWxkIGxpa2UsDQogeW91IG1heSBjb25zdHJ1Y3QgeW91 ciBjaGFpbiB0byBiZSBhIGNoYWluIG9mIFNGIExCcywgZWFjaCB3aXRoIGEgc2luZ2xlIGluc3Rh bmNlPyAmbmJzcDtUaGF0IHdvdWxkIGFsbG93IHlvdSB0byBzY2FsZSBhdCB0aGUgY29zdCBvZiB0 aGUgaW5jcmVtZW50YWwgbGF0ZW5jeSB0aGF0IGluaGVyZW50bHkgY29tZXMgd2l0aCBzY2FsaW5n LCBidXQgYWxzbyBhbGxvdyBhIHNtYWxsZXIgaW1wbGVtZW50YXRpb24gdG8gZm9yZ28gdGhlIExC cyBhbmQgcGVyZm9ybQ0KIHRoZSBkaXN0cmlidXRpb24gZnVuY3Rpb24gYXQgdGhlIENsYXNzaWZp ZXIuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5DYXRoeSZndDsgU3VyZSwgSSBhbSBmaW5lIHdpdGggdGhlIHNheWluZyBleGNl cHQgdGhhdCB0aGUgY2hhaW4gY2FuIGJlIGEgY29tYmluYXRpb24gb2Yg4oCcU0YgTEJzIGFuZCBz ZXJ2aWNlIGluc3RhbmNlc+KAnSBpbnN0ZWFkIG9mIOKAnGEgY2hhaW4gb2YgU0YgTEJz4oCdLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206Ni43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9 IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ni43NXB0Ij48Yj5Gcm9tOiA8L2I+Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tJmx0O0NhdGh5 LkguWmhhbmdAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5UbzogPC9iPk5BUElFUkFMQSwgTUFSSUEg SCZsdDttbjE5MjFAYXR0LmNvbSZndDssUm9uIFBhcmtlciZsdDtSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tJmd0OyxKb2VsIEhhbHBlcm4gRGlyZWN0Jmx0O2ptaC5kaXJlY3RAam9lbGhh bHBlcm4uY29tJmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDss RXJpayBOb3JkbWFyayZsdDtub3JkbWFya0BhY20ub3JnJmd0OyxLZXZpbiBKIE1hJmx0O2tldmlu Lm1hQGF6dWtpc3lzdGVtcy5jb20mZ3Q7LERhdmUgRG9sc29uJmx0O2Rkb2xzb25Ac2FuZHZpbmUu Y29tJmd0OyxTdW1hbmRyYQ0KIE1hamVlJmx0O1MuTWFqZWVARjUuY29tJmd0Ozxicj4NCjxiPmNj OiA8L2I+c2ZjQGlldGYub3JnJmx0O3NmY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TZW50OiA8L2I+ V2VkbmVzZGF5LCBNYXJjaCAyNiwgMjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10g U0ZDIGVuY2Fwc3VsYXRpb24gY2hhaW4gSUQ8YnI+DQo8YnI+DQpIb3BzIGNhbiBiZSBtaXRpZ2F0 ZWQgYnkgcnVubmluZyB0aGUgTEIgaW4gdGhlIHNhbWUgbG9jYXRpb24gYXMgdGhvc2UgU0YgVk1z IDxicj4NClRoZSBjb25uZWN0aW9uIGZyb20gTEIgdG8gdGhvc2UgU0YgVk1zIGlzIGxvY2FsLCBu b3QgaG9wcy4gPGJyPg0KPGJyPg0KQ2F0aHk8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCjxicj4NCjxicj4NCkZyb206IE5BUElFUkFMQSwgTUFSSUEgSCBbbWFpbHRv Om1uMTkyMUBhdHQuY29tXSA8YnI+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0IDEw OjU3IEFNPGJyPg0KVG86IENhdGh5IFpoYW5nOyBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGly ZWN0OyBKb2VsIE0uIEhhbHBlcm47IEVyaWsgTm9yZG1hcms7IEtldmluIEogTWE7IERhdmUgRG9s c29uOyBTdW1hbmRyYSBNYWplZTxicj4NCkNjOiBzZmNAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBS RTogW3NmY10gU0ZDIGVuY2Fwc3VsYXRpb24gY2hhaW4gSUQ8YnI+DQo8YnI+DQomZ3Q7IDxicj4N CiZndDsgSWYgY2FzZSAxIHBvc2VzIGEgc2NhbGFiaWxpdHkgcHJvYmxlbSAoZWcuIHRoZXJlIGFy ZSBodW5kcmVkcyBvZiBWTXM8YnI+DQomZ3Q7IGZvciBhIHNlcnZpY2UgZnVuY3Rpb24pLCB0aGUg c2NhbGFiaWxpdHkgaXNzdWUgY2FuIGJlIHNvbHZlZCBieTxicj4NCiZndDsgdHJhbnNmb3JtaW5n IGNhc2UgMSBpbnRvIGNhc2UgMjxicj4NCiZndDsgdGhyb3VnaCBwbGFjaW5nIGEgbG9jYWwgTEIg YmVmb3JlIHRoZXNlIFZNcyBhbmQgb25seSB0aGUgTEIgaXMgdmlld2VkPGJyPg0KJmd0OyBpbiB0 aGUgY2hhaW4uIDxicj4NCjxicj4NCkludHJvZHVjaW5nIGFkZGl0aW9uYWwgaG9wIGlzIGEgc2Vy dmljZSBjaGFpbiB0cmFuc2xhdGVzIHRvIGRlbGF5IGFuZCBjb3N0LiBJbWFnaW5lIGEgNSBob3Ag Y2hhaW4sIGVhY2ggZnJvbnRlZCB3aXRoIGFuIGV4dGVybmFsIExCIFNGLiA1LWhvcCBjaGFpbiBi ZWNvbWVzIDEwLWhvcCBjaGFpbi4NCjxicj4NCkluIGZhY3QsIGlmIHRoZSBMQiBpcyBhIHZpcnR1 YWwgYXBwbGlhbmNlIGl0IG1pZ2h0IGhhdmUgc2ltaWxhciBzY2FsYWJpbGl0eSBpc3N1ZSBhcyB0 aGUgb3JpZ2luYWwgU0YuPGJyPg0KPGJyPg0KJmd0OyBJbiBzb21lIG90aGVyIGRlcGxveW1lbnQg c2NlbmFyaW8sIGNhc2UgMSBtaWdodCBub3QgcG9zZTxicj4NCiZndDsgYSBzY2FsYWJpbGl0eSBp c3N1ZSwgYW5kPGJyPg0KJmd0OyB0aHVzIHNvbHV0aW9uL2FyY2hpdGVjdHVyZSB3aXNlLCB3ZSBz aG91bGQgbm90IGV4Y2x1ZGUgY2FzZSAxLiBUbyBwdXQ8YnI+DQomZ3Q7IGl0IGFub3RoZXIgd2F5 LCBjYXNlIDEgaXMgb25seSB1c2FibGUgaW4gc21hbGwtc2NhbGUgc2NlbmFyaW8uPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IENhdGh5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE5BUElFUkFMQSwgTUFSSUEgSDxicj4NCiZndDsgU2VudDogV2VkbmVz ZGF5LCBNYXJjaCAyNiwgMjAxNCA4OjQ4IEFNPGJyPg0KJmd0OyBUbzogUm9uIFBhcmtlcjsgSm9l bCBIYWxwZXJuIERpcmVjdDsgSm9lbCBNLiBIYWxwZXJuOyBFcmlrIE5vcmRtYXJrOzxicj4NCiZn dDsgS2V2aW4gSiBNYTsgRGF2ZSBEb2xzb247IFN1bWFuZHJhIE1hamVlPGJyPg0KJmd0OyBDYzog c2ZjQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU0ZDIGVuY2Fwc3VsYXRp b24gY2hhaW4gSUQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgUm9uLDxicj4NCiZndDsgPGJyPg0KJmd0 OyBJIHdvdWxkIGNvbnNpZGVyIGEgc29sdXRpb24gd2hpY2ggc2NhbGVzIG9ubHkgd2l0aCBhc3N1 bXB0aW9ucyAyLiBhbmQ8YnI+DQomZ3Q7IDMuIChjbHVzdGVycyB3aXRoIGludGVybmFsIExCKSBh cyBsaW1pdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBNYXJpYTxicj4NCiZndDsgPGJyPg0KJmd0 OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IFJv biBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXTxicj4NCiZn dDsgJmd0OyBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI2LCAyMDE0IDExOjQ0IEFNPGJyPg0KJmd0 OyAmZ3Q7IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgSGFscGVybiBEaXJlY3Q7IEpvZWwg TS4gSGFscGVybjsgRXJpazxicj4NCiZndDsgJmd0OyBOb3JkbWFyazsgS2V2aW4gSiBNYTsgRGF2 ZSBEb2xzb247IFN1bWFuZHJhIE1hamVlPGJyPg0KJmd0OyAmZ3Q7IENjOiBzZmNAaWV0Zi5vcmc8 YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUkU6IFtzZmNdIFNGQyBlbmNhcHN1bGF0aW9uIGNoYWlu IElEPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE1hcmlhLDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBJIGFncmVlIHdpdGggeW91IHRoYXQgY2FzZSAxLiB3aWxsIG9ubHkgcHJh Y3RpY2FsbHkgc2NhbGUgdXAgdG8gc29tZTxicj4NCiZndDsgJmd0OyBwb2ludC4gJm5ic3A7Jm5i c3A7IFBlcmhhcHMsIGFzIGEgc2VydmljZSBwcm92aWRlciwgeW91J2QgY2hvb3NlIHRvIGF2b2lk IHRoZTxicj4NCiZndDsgJmd0OyB3aG9sZSBwcm9ibGVtIGFuZCBvbmx5IGRlcGxveSBzZXJ2aWNl IGZ1bmN0aW9ucyBhbG9uZyB0aGUgbGluZXMgb2Y8YnI+DQomZ3Q7IGNhc2U8YnI+DQomZ3Q7ICZn dDsgMiBvciBjYXNlIDMuICZuYnNwOyZuYnNwOyBCdXQsIHRoYXQgZG9lc24ndCBpbnZhbGlkYXRl IHRoZSB1dGlsaXR5IG9mIGNhc2UgMTxicj4NCiZndDsgZm9yPGJyPg0KJmd0OyAmZ3Q7IHNvbWUg b3RoZXIgbmV0d29yayB3aXRoIHNvbWUgb3RoZXIgcmVxdWlyZW1lbnRzIGFuZCBjb25zdHJhaW50 cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7Jm5ic3A7IFJvbjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBOQVBJRVJBTEEsIE1BUklBIEggW21haWx0bzpt bjE5MjFAYXR0LmNvbV08YnI+DQomZ3Q7ICZndDsgU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNiwg MjAxNCAxMTozOSBBTTxicj4NCiZndDsgJmd0OyBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJu IERpcmVjdDsgSm9lbCBNLiBIYWxwZXJuOyBFcmlrIE5vcmRtYXJrOzxicj4NCiZndDsgJmd0OyBL ZXZpbiBKIE1hOyBEYXZlIERvbHNvbjsgU3VtYW5kcmEgTWFqZWU8YnI+DQomZ3Q7ICZndDsgQ2M6 IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSRTogW3NmY10gU0ZDIGVuY2Fw c3VsYXRpb24gY2hhaW4gSUQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IDEuIEEgc2VydmljZSBmdW5jdGlvbiBpcyByZWFsaXplZCBieSBtdWx0 aXBsZSBWTSdzIHdoZXJlIGVhY2ggVk08YnI+DQomZ3Q7IGhhczxicj4NCiZndDsgJmd0OyAmZ3Q7 IGl0cyBvd24gSVAgYWRkcmVzcy4gJm5ic3A7IEluIHRoaXMgY2FzZSB0aGUgY2xhc3NpZmllci9Q RFAgc2VlcyBlYWNoIFZNPGJyPg0KJmd0OyBhczxicj4NCiZndDsgJmd0OyBhPGJyPg0KJmd0OyAm Z3Q7ICZndDsgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGRvbid0IHRoaW5rIHRoaXMgd2lsbCBzY2Fs ZS4gSXQgd2FzIHBvaW50ZWQgb3V0IHRoYXQgdGhlIG51bWJlciBvZjxicj4NCiZndDsgJmd0OyBz ZXJ2aWNlIHBhdGhzIGdyb3dzIGV4cG9uZW50aWFsbHkuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgMi4gQSBzZXJ2aWNlIGZ1bmN0aW9uLCBhcyBhYm92 ZSwgYnV0IHNvbWUgc3Vic2V0IG9mIFZNJ3MgaXMgZnJvbnQtPGJyPg0KJmd0OyAmZ3Q7IGVuZGVk PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYnkgYSBsb2FkIGJhbGFuY2VyLiAmbmJzcDsgVGhlcmUgYXJl IG11bHRpcGxlIHN1Y2ggc3Vic2V0cyBhbmQgdGhlcmVmb3JlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg bXVsdGlwbGUgbG9hZCBiYWxhbmNlcnMuICZuYnNwOyBFYWNoIGxvYWQgYmFsYW5jZXIgaGFzIGl0 cyBvd24gSVA8YnI+DQomZ3Q7IGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsgJmd0OyBhbmQgaGlkZXMg dGhlIFZNIElQIGFkZHJlc3NlcyBiZWhpbmQgaXQuICZuYnNwOyBJbiB0aGlzIGNhc2UsIHRoZTxi cj4NCiZndDsgJmd0OyAmZ3Q7IGNsYXNzaWZpZXIvUERQIHNlZXMgZWFjaCBsb2FkIGJhbGFuY2Vy IGFzIGEgc2VydmljZSBmdW5jdGlvbjxicj4NCiZndDsgJmd0OyBpbnN0YW5jZS48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgTm8gaXNzdWUgaGVyZS48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAzLiBBIHNlcnZpY2UgZnVuY3Rpb24gaXMgcmVhbGl6ZWQgYnkgYSBzZXQg b2YgVk0ncyB0aGF0IHBlcmZvcm08YnI+DQomZ3Q7ICZndDsgJmd0OyBpbnRlcm5hbCBsb2FkIGJh bGFuY2luZy4gJm5ic3A7IFRoZSBzZXQgb2YgVk0ncyBwcmVzZW50cyBhIHNpbmdsZSBJUDxicj4N CiZndDsgJmd0OyBhZGRyZXNzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG8gdGhlIG91dHNpZGUgdG8g aGlkZSB0aGUgSVAgYWRkcmVzc2VzIG9mIHRoZSBpbmRpdmlkdWFsIFZNcy48YnI+DQomZ3Q7IFRo ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG5ldHdvcmsgaGFzIG11bHRpcGxlIHN1Y2ggY2x1c3RlcnMu ICZuYnNwOyBUaGUgY2xhc3NpZmllci9QRFAgc2VlcyBlYWNoPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Y2x1c3RlciBhcyBhIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogTkFQSUVSQUxBLCBNQVJJQSBIIFttYWlsdG86bW4x OTIxQGF0dC5jb21dPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2VudDogV2VkbmVzZGF5LCBNYXJjaCAy NiwgMjAxNCAxMToxNyBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiBKb2VsIEhhbHBlcm4gRGly ZWN0OyBKb2VsIE0uIEhhbHBlcm47IEVyaWsgTm9yZG1hcms7IEtldmluIEo8YnI+DQomZ3Q7IE1h Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFJvbiBQYXJrZXI7IERhdmUgRG9sc29uOyBTdW1hbmRyYSBN YWplZTxicj4NCiZndDsgJmd0OyAmZ3Q7IENjOiBzZmNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsg Jmd0OyBTdWJqZWN0OiBSRTogW3NmY10gU0ZDIGVuY2Fwc3VsYXRpb24gY2hhaW4gSUQ8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEpvZWwsPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBwb2ludCBvZiB0aGUgZGlzdGluY3Rpb24g d2FzIGJldHdlZW4gb24gdGhlIG9uZSBoYW5kIGxvYWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGJhbGFuY2luZyBhcyBwYXJ0IG9mIHRoZSBjaGFpbiBmb3IgdGhlIHB1cnBvc2Ugb2Ygc2VsZWN0 aW5nIGFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbnN0YW5jZSBvZiB0aGUgYWN0dWFsbHkg YWRkcmVzc2VkIGRlc3RpbmF0aW9uIChpLmUuIHRoZSBsb2FkPGJyPg0KJmd0OyAmZ3Q7ICZndDsg YmFsYW5jZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGlzIHZpc2libGUgdG8gdGhlIHRlbmFu dCBhbmQgaXMgdGhlcmUgZm9yIHRoZSBwdXJwb3NlIHRoZSB0ZW5hbnQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHJlcXVlc3Q7IGFuZCBvbiB0aGUgb3RoZXIgaGFuZCBhIGxvYWQgYmFsYW5jZXIg d2hpY2ggaXMga25vd24gdG88YnI+DQomZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlLCBidXQgd2hvc2UgcHVycG9zZSB0 byBiYWxhbmNlPGJyPg0KJmd0OyAmZ3Q7IGFjcm9zczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg aXNudGFuY2VzIG9mIHNlcnZpY2VzIHdob3NlIG11bHRpcGxpY2l0eSBpcyBub3Qgb2YgY29uY2Vy biB0byB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRlbmFudCwgb25seSB0aGUgZnVuY3Rp b25hbGl0eS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBQdXQgZGlmZmVyZW50bHksIGl0IGlzIGJldHdlZW4gbG9hZCBiYWxhbmNpbmcgYXMgYW4gZXhw bGljaXQ8YnI+DQomZ3Q7ICZndDsgc2VydmljZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYW5k IGxvYWQgYmFsYW5jaW5nIHRvIGVuYWJsZSBzb21lIHNlcnZpY2Ugd2l0aGluIHRoZSBzZXJ2aWNl PGJyPg0KJmd0OyAmZ3Q7ICZndDsgY2hhaW5pbmcuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyBUaGFua3MgZm9yIGNsYXJpZmljYXRpb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTXkgY29uY2Vy biBpcyBhYm91dCB0aGUgbGF0dGVyLCBpLmUuLCBTRkMgc29sdXRpb24gbXVzdCBzdXBwb3J0PGJy Pg0KJmd0OyBsb2FkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYmFsYW5jaW5nIHRvIG11bHRpcGxlIHNl cnZpY2UgaW5zdGFudGlhdGlvbnMgKGUuZy4sIFZNcykgb2YgYTxicj4NCiZndDsgc2luZ2xlPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgc2VydmljZSBhdCB0aGUgaW50ZXJtZWRpYXRlIHNlcnZpY2UgaG9w cy4gSW4gZmFjdCwgd2UgbmVlZCB0aGU8YnI+DQomZ3Q7IGxhdHRlcjxicj4NCiZndDsgJmd0OyAm Z3Q7IHRvIHN1cHBvcnQgdGhlIGZvcm1lci4uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyBNYXJpYTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT24gMy8yNi8xNCwgMTA6NTYgQU0sIE5BUElF UkFMQSwgTUFSSUEgSCB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IDEpIGdpdmVuIHRoZSByYW5nZSBvZiBsb2FkIGJh bGFuY2luZyBiZWhhdmlvcnMsIHN1cHBydGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyZndDsgZXhwbGljaXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxvYWQ8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IGJhbGFuY2VycyBpbiB0aGUgc2VydmljZSBjaGFpbmluZyAo YXMgZGlzdGluY3QgZnJvbSBzdXBwb3J0aW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbG9hZDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgYmFsYW5jZXJzIGZvciBlbmQgdXNlcnMpLCBp cyBzaWduaWZpY2FudGx5IGNvbXBsaWNhdGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQg dGhpcyBwb2ludC4gQ291bGQgeW91IGV4cGxhaW4gd2hhdDxicj4NCiZndDsgeW91PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBtZWFuIGJ5ICZxdW90O2V4cGxpY2l0JnF1b3Q7IGxvYWQgYmFsYW5j ZXIgdnMuIGxvYWQgYmFsYW5jZXIgJnF1b3Q7Zm9yIHRoZSBlbmQ8YnI+DQomZ3Q7ICZndDsgJmd0 OyB1c2VycyZxdW90Oz88YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQpzZmNAaWV0Zi5vcmc8 YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A2C96F6779E6A041BC7023CC207FC99418F2752ESJCEML703CHMchi_-- From nobody Thu Apr 3 15:55: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 A70951A034C for ; Thu, 3 Apr 2014 15:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 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, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 T8z4l0_Uoxp1 for ; Thu, 3 Apr 2014 15:55:32 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) by ietfa.amsl.com (Postfix) with ESMTP id 76FAC1A034D for ; Thu, 3 Apr 2014 15:55:32 -0700 (PDT) Received: from mtaout-mad02.mx.aol.com (mtaout-mad02.mx.aol.com [172.26.221.206]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id E3A217000009E; Thu, 3 Apr 2014 18:55:27 -0400 (EDT) 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-mad02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B351538000092; Thu, 3 Apr 2014 18:55:27 -0400 (EDT) Date: Thu, 3 Apr 2014 18:55:26 -0400 From: "mikebianc@aol.com" To: Cathy.H.Zhang@huawei.com Message-ID: <334812563.38955.1396565726775.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: References: <291CC3F9E50E7641901A54E85D0977C6E7B88FB165@MAILR002.mail.lan> <53308576.6030107@acm.org> <5330A283.6050007@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361692@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332E76D.6010809@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E013617DD@MISOUT7MSGUSR9I.ITServices.sbc.com> <5332EBA7.3000100@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361830@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E013619D0@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361A1A@MISOUT7MSGUSR9I.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01361B80@MISOUT7MSGUSR9I.ITServices.sbc.com> <1516725807.33000.1396392616203.JavaMail.tomcat@mgs-aam01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38954_296836992.1396565726775" X-Originating-IP: 10.181.180.169, 64.12.173.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=1396565727; bh=cUFZC507grIQpiTeTMa+fwsPFbJxxQBVxP7iS0PwmX0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=D0Zq8HT1efSxBZx8j1omFQ6Z75Up3GR890xfUX9RsRs2IEE+Y+8BdAWNuuz4lw1mm fpEnpcnoh53FHTybhv8pIO4hsAl9z+VRC8VKTrzBsEheW5hfbFW0FgFT8nRCSIrrPB ZcttAPxTb5JNTcL7jMbiX94npp9IhYWsaOeR0rK4= x-aol-sid: 3039ac1addce533de6df2a2f X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wg6Xzi-QnPRNljrBm9s5VbmNavA Cc: sfc@ietf.org Subject: Re: [sfc] SFC encapsulation chain ID 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, 03 Apr 2014 22:55:36 -0000 ------=_Part_38954_296836992.1396565726775 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable sounds like we are more or less in agreement. From: Cathy.H.Zhang@huawei.com To: mikebianc@aol.com cc: sfc@ietf.org Sent: Thursday, April 3, 2014 Subject: RE: [sfc] SFC encapsulation chain ID Just come back from my PTO. Please see inline. =20 Thanks, Cathy =20 From: mikebianc@aol.com [mailto:mikebianc@aol.com] Sent: Tuesday, April 01, 2014 3:50 PM To: Cathy Zhang Cc: sfc@ietf.org Subject: Re: [sfc] SFC encapsulation chain ID =20 In this case, it is still a hop. The LB VM still has to process (and "bala= nce") the packets, which incurs a larger penalty than the 500ns (or so) of = a physical network hop. Additionally, the "hop" that you say is mitigated is only mitigated if yo= u colocate all of the VMs behind a LB instance with the LB itself, which is= not very elastic, requiring one to create multiple instances of LBs for th= e same SF, which requires either having instances chosen by an SFC classifier (which you are trying to avoi= d) or introducing a LB in a different location to balance between multiple = local LBs (fronting the SF VM instances), which simply re-introduces the ho= ps that you were trying to mitigate in the first place. I suppose you could implement this in such a way that= you had a LB in front of your SFC Classifier, but I'd have to wrap my head= around that some more to see if it even makes sense. Either way, I don't = think this solves what you think it solves. =20 Cathy> It depends on what is meant by =E2=80=9Ca hop=E2=80=9D. The semantic= s of the =E2=80=9Cstill a hop=E2=80=9D is different from the physical netwo= rk hop which was meant in my previous reply. =20 BTW, network hop latency could be larger than 500ns and worse than local pr= ocessing latency if the network has congestion. Yes, the =E2=80=9Chop=E2=80=9D is only mitigated if the VM instance cluster= associated with the same service function is not large and is collocated w= ith the LB. For scenarios that VM instances associated with a service function are of l= arge size and widely distributed, multiple LBs might be needed to front-end= the VMs and the classifier needs to be aware of these LBs. Or some other better mechan= ism needs to be sorted out to solve the scalability issue (too many service= paths with permutations of service instances). Yes, we are in sync that front ending VM cluster with a LB incurs extra pro= cessing and latency. =20 As discussed in this email thread before, everything has a scale limit and = scalability enhancement mechanisms usually incur some cost and application = limitation. =20 Why can't we simply say that the SFC classifier chooses the SFC Path (speci= fic SF instances) and as a matter of implementation, if you would like, you may construct your chain to be a chain of SF LBs, each with a single i= nstance? That would allow you to scale at the cost of the incremental late= ncy that inherently comes with scaling, but also allow a smaller implementa= tion to forgo the LBs and perform the distribution function at the Classifier. Cathy> Sure, I am fine with the saying except that the chain can be a combi= nation of =E2=80=9CSF LBs and service instances=E2=80=9D instead of =E2=80= =9Ca chain of SF LBs=E2=80=9D. =20 From: Cathy.H.Zhang@huawei.com To: NAPIERALA, MARIA H,Ron Parker,Joel Halpern Direct,Joel M. Halpern,Erik Nordmark,Kevin J Ma,Dave Dolson,Sumandra Majee cc: sfc@ietf.org Sent: Wednesday, March 26, 2014 Subject: Re: [sfc] SFC encapsulation chain ID Hops can be mitigated by running the LB in the same location as those SF VM= s=20 The connection from LB to those SF VMs is local, not hops.=20 Cathy -----Original Message----- From: NAPIERALA, MARIA H [mailto:mn1921@att.com]=20 Sent: Wednesday, March 26, 2014 10:57 AM To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nor= dmark; Kevin J Ma; Dave Dolson; Sumandra Majee Cc: sfc@ietf.org Subject: RE: [sfc] SFC encapsulation chain ID >=20 > If case 1 poses a scalability problem (eg. there are hundreds of VMs > for a service function), the scalability issue can be solved by > transforming case 1 into case 2 > through placing a local LB before these VMs and only the LB is viewed > in the chain.=20 Introducing additional hop is a service chain translates to delay and cost.= Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop chain be= comes 10-hop chain. In fact, if the LB is a virtual appliance it might have similar scalability= issue as the original SF. > In some other deployment scenario, case 1 might not pose > a scalability issue, and > thus solution/architecture wise, we should not exclude case 1. To put > it another way, case 1 is only usable in small-scale scenario. >=20 > Cathy >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA H > Sent: Wednesday, March 26, 2014 8:48 AM > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark ; > Kevin J Ma; Dave Dolson; Sumandra Majee > Cc: sfc@ietf.org > Subject: Re: [sfc] SFC encapsulation chain ID >=20 > Ron, >=20 > I would consider a solution which scales only with assumptions 2. and > 3. (clusters with internal LB) as limited. >=20 > Maria >=20 > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: Wednesday, March 26, 2014 11:44 AM > > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; Erik > > Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee > > Cc: sfc@ietf.org > > Subject: RE: [sfc] SFC encapsulation chain ID > > > > Maria, > > > > I agree with you that case 1. will only practically scale up to some > > point. Perhaps, as a service provider, you'd choose to avoid the > > whole problem and only deploy service functions along the lines of > case > > 2 or case 3. But, that doesn't invalidate the utility of case 1 > for > > some other network with some other requirements and constraints. > > > > Ron > > > > > > -----Original Message----- > > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > > Sent: Wednesday, March 26, 2014 11:39 AM > > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark ; > > Kevin J Ma; Dave Dolson; Sumandra Majee > > Cc: sfc@ietf.org > > Subject: RE: [sfc] SFC encapsulation chain ID > > > > > > > > 1. A service function is realized by multiple VM's where each VM > has > > > its own IP address. In this case the classifier/PDP sees each VM > as > > a > > > service function instance. > > > > > > > I don't think this will scale. It was pointed out that the number of > > service paths grows exponentially. > > > > > > > 2. A service function, as above, but some subset of VM's is front- > > ended > > > by a load balancer. There are multiple such subsets and therefore > > > multiple load balancers. Each load balancer has its own IP > address > > > and hides the VM IP addresses behind it. In this case, the > > > classifier/PDP sees each load balancer as a service function > > instance. > > > > No issue here. > > > > > 3. A service function is realized by a set of VM's that perform > > > internal load balancing. The set of VM's presents a single IP > > address > > > to the outside to hide the IP addresses of the individual VMs. > The > > > network has multiple such clusters. The classifier/PDP sees each > > > cluster as a service function instance. > > > > > > > > > > > > > > > -----Original Message----- > > > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > > > Sent: Wednesday, March 26, 2014 11:17 AM > > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J > Ma ; > > > Ron Parker; Dave Dolson; Sumandra Majee > > > Cc: sfc@ietf.org > > > Subject: RE: [sfc] SFC encapsulation chain ID > > > > > > Joel, > > > > > > > The point of the distinction was between on the one hand load > > > > balancing as part of the chain for the purpose of selecting an > > > > instance of the actually addressed destination (i.e. the load > > > balancer > > > > is visible to the tenant and is there for the purpose the tenant > > > > request; and on the other hand a load balancer which is known to > > the > > > > service chaining infrastructure, but whose purpose to balance > > across > > > > isntances of services whose multiplicity is not of concern to the > > > > tenant, only the functionality. > > > > > > > > Put differently, it is between load balancing as an explicit > > service > > > > and load balancing to enable some service within the service > > > chaining. > > > > > > > > > > > > > Thanks for clarification. > > > My concern is about the latter, i.e., SFC solution must support > load > > > balancing to multiple service instantiations (e.g., VMs) of a > single > > > service at the intermediate service hops. In fact, we need the > latter > > > to support the former.. > > > > > > Maria > > > > > > > > > > > On 3/26/14, 10:56 AM, NAPIERALA, MARIA H wrote: > > > > > > > > > >> 1) given the range of load balancing behaviors, supprting > > > > >> explicit > > > > load > > > > >> balancers in the service chaining (as distinct from supporting > > > load > > > > >> balancers for end users), is significantly complicate > > > > > > > > > > I am not sure I understand this point. Could you explain what > you > > > > mean by "explicit" load balancer vs. load balancer "for the end > > > users"? >=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 ------=_Part_38954_296836992.1396565726775 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
sounds like we = are more or less in agreement.


From: Cathy.H.Zhang@huawei.com<Cathy.H.Zhang@huawei.co= m>
To: mikebianc@aol.com<mikebianc@aol.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, April 3, 2014<= br>Subject: RE: [sfc] SFC encapsulation chain ID

Just come back from my PT= O. Please see inline.

Thanks,=

Cathy

From: mikeb= ianc@aol.com [mailto:mikebianc@aol= .com]
Sent: Tuesday, April 01, 2014 3:50 PM
To: Cathy Zhang
Cc: sfc@ietf.org
Subject: Re: [sfc] SFC encapsulation chain ID

In this case, it is still a hop. The LB = VM still has to process (and "balance") the packets, which incurs a larger = penalty than the 500ns (or so) of a physical network hop. Additionally, the "hop" that you say is mitigated is only mitigated if yo= u colocate all of the VMs behind a LB instance with the LB itself, which is= not very elastic, requiring one to create multiple instances of LBs for th= e same SF, which requires either having instances chosen by an SFC classifier (which you are trying to avoi= d) or introducing a LB in a different location to balance between multiple = local LBs (fronting the SF VM instances), which simply re-introduces the ho= ps that you were trying to mitigate in the first place. I suppose you could implement this in such a way that= you had a LB in front of your SFC Classifier, but I'd have to wrap my head= around that some more to see if it even makes sense. Either way, I don't = think this solves what you think it solves.

Cathy> It depends o= n what is meant by =E2=80=9Ca hop=E2=80=9D. The semantics of the =E2=80=9Cs= till a hop=E2=80=9D is different from the physical network hop which was me= ant in my previous reply.

BTW, network hop laten= cy could be larger than 500ns and worse than local processing latency if th= e network has congestion.

Yes, the =E2=80=9Chop= =E2=80=9D is only mitigated if the VM instance cluster associated with the = same service function is not large and is collocated with the LB.

For scenarios that VM = instances associated with a service function are of large size and widely d= istributed, multiple LBs might be needed to front-end the VMs and

the classifier needs t= o be aware of these LBs. Or some other better mechanism needs to be sorted= out to solve the scalability issue (too many service paths with permutatio= ns of service instances).

Yes, we are in sync th= at front ending VM cluster with a LB incurs extra processing and latency. =

As discussed in this e= mail thread before, everything has a scale limit and scalability enhancemen= t mechanisms usually incur some cost and application limitation.

Why can't = we simply say that the SFC classifier chooses the SFC Path (specific SF ins= tances) and as a matter of implementation, if you would like, you may construct your chain to be a chain of SF LBs, each with a single i= nstance? That would allow you to scale at the cost of the incremental late= ncy that inherently comes with scaling, but also allow a smaller implementa= tion to forgo the LBs and perform the distribution function at the Classifier.

Cathy> Sure, I am fine with the saying except that the chain ca= n be a combination of =E2=80=9CSF LBs and service instances=E2=80=9D instea= d of =E2=80=9Ca chain of SF LBs=E2=80=9D.

From: Cathy.H.Zhang@huawei.com<Cathy.H.Zhang@huawei.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>,Ron Parker<Ron_Parker@affirmednetworks.com>,Joel Halpern Direct<jmh.direct@joelhalpern.com>,J= oel M. Halpern<jmh@joelhalpern.co= m>,Erik Nordmark<nordmark@acm= .org>,Kevin J Ma<kev= in.ma@azukisystems.com>,Dave Dolson<ddolson@sandvine.com>,Sumandra Majee<S.Majee@F5.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Wednesday, March 26, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

Hops can be mitigated by running the LB in the same location as those SF VM= s
The connection from LB to those SF VMs is local, not hops.

Cathy

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


From: NAPIERALA, MARIA H [mailto:mn1921@a= tt.com]
Sent: Wednesday, March 26, 2014 10:57 AM
To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nor= dmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: sfc@ietf.org
Subject: RE: [sfc] SFC encapsulation chain ID

>
> If case 1 poses a scalability problem (eg. there are hundreds of VMs > for a service function), the scalability issue can be solved by
> transforming case 1 into case 2
> through placing a local LB before these VMs and only the LB is viewed<= br> > in the chain.

Introducing additional hop is a service chain translates to delay and cost.= Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop chain be= comes 10-hop chain.
In fact, if the LB is a virtual appliance it might have similar scalability= issue as the original SF.

> In some other deployment scenario, case 1 might not pose
> a scalability issue, and
> thus solution/architecture wise, we should not exclude case 1. To put<= br> > it another way, case 1 is only usable in small-scale scenario.
>
> Cathy
>
> -----Original Message-----
> From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of NAPIERALA, MARIA H
> Sent: Wednesday, March 26, 2014 8:48 AM
> To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; > Kevin J Ma; Dave Dolson; Sumandra Majee
> Cc: sfc@ietf.org
> Subject: Re: [sfc] SFC encapsulation chain ID
>
> Ron,
>
> I would consider a solution which scales only with assumptions 2. and<= br> > 3. (clusters with internal LB) as limited.
>
> Maria
>
> > -----Original Message-----
> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
> > Sent: Wednesday, March 26, 2014 11:44 AM
> > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; Eri= k
> > Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
> > Cc: sfc@ietf.org
> > Subject: RE: [sfc] SFC encapsulation chain ID
> >
> > Maria,
> >
> > I agree with you that case 1. will only practically scale up to s= ome
> > point. Perhaps, as a service provider, you'd choose to avoid t= he
> > whole problem and only deploy service functions along the lines o= f
> case
> > 2 or case 3. But, that doesn't invalidate the utility of case = 1
> for
> > some other network with some other requirements and constraints.<= br> > >
> > Ron
> >
> >
> > -----Original Message-----
> > From: NAPIERALA, MARIA H [mailt= o:mn1921@att.com]
> > Sent: Wednesday, March 26, 2014 11:39 AM
> > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordma= rk;
> > Kevin J Ma; Dave Dolson; Sumandra Majee
> > Cc: sfc@ietf.org
> > Subject: RE: [sfc] SFC encapsulation chain ID
> >
> > >
> > > 1. A service function is realized by multiple VM's where eac= h VM
> has
> > > its own IP address. In this case the classifier/PDP sees e= ach VM
> as
> > a
> > > service function instance.
> > >
> >
> > I don't think this will scale. It was pointed out that the number= of
> > service paths grows exponentially.
> >
> >
> > > 2. A service function, as above, but some subset of VM's is = front-
> > ended
> > > by a load balancer. There are multiple such subsets and th= erefore
> > > multiple load balancers. Each load balancer has its own IP=
> address
> > > and hides the VM IP addresses behind it. In this case, the=
> > > classifier/PDP sees each load balancer as a service function=
> > instance.
> >
> > No issue here.
> >
> > > 3. A service function is realized by a set of VM's that perf= orm
> > > internal load balancing. The set of VM's presents a single= IP
> > address
> > > to the outside to hide the IP addresses of the individual VM= s.
> The
> > > network has multiple such clusters. The classifier/PDP see= s each
> > > cluster as a service function instance.
> >
> >
> >
> > >
> > >
> > > -----Original Message-----
> > > From: NAPIERALA, MARIA H [= mailto:mn1921@att.com]
> > > Sent: Wednesday, March 26, 2014 11:17 AM
> > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kev= in J
> Ma;
> > > Ron Parker; Dave Dolson; Sumandra Majee
> > > Cc: sfc@ietf.org
> > > Subject: RE: [sfc] SFC encapsulation chain ID
> > >
> > > Joel,
> > >
> > > > The point of the distinction was between on the one han= d load
> > > > balancing as part of the chain for the purpose of selec= ting an
> > > > instance of the actually addressed destination (i.e. th= e load
> > > balancer
> > > > is visible to the tenant and is there for the purpose t= he tenant
> > > > request; and on the other hand a load balancer which is= known to
> > the
> > > > service chaining infrastructure, but whose purpose to b= alance
> > across
> > > > isntances of services whose multiplicity is not of conc= ern to the
> > > > tenant, only the functionality.
> > > >
> > > > Put differently, it is between load balancing as an exp= licit
> > service
> > > > and load balancing to enable some service within the se= rvice
> > > chaining.
> > > >
> > >
> > >
> > > Thanks for clarification.
> > > My concern is about the latter, i.e., SFC solution must supp= ort
> load
> > > balancing to multiple service instantiations (e.g., VMs) of = a
> single
> > > service at the intermediate service hops. In fact, we need t= he
> latter
> > > to support the former..
> > >
> > > Maria
> > >
> > > >
> > > > On 3/26/14, 10:56 AM, NAPIERALA, MARIA H wrote:
> > > > >
> > > > >> 1) given the range of load balancing behaviors= , supprting
> > > > >> explicit
> > > > load
> > > > >> balancers in the service chaining (as distinct= from supporting
> > > load
> > > > >> balancers for end users), is significantly com= plicate
> > > > >
> > > > > I am not sure I understand this point. Could you e= xplain what
> you
> > > > mean by "explicit" load balancer vs. load balancer "for= the end
> > > users"?
>
> _______________________________________________
> 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_38954_296836992.1396565726775-- From nobody Thu Apr 3 22:45: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 E783B1A02F9 for ; Thu, 3 Apr 2014 22:45:57 -0700 (PDT) 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 p3h8vHnViFzS for ; Thu, 3 Apr 2014 22:45:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D659E1A02BE for ; Thu, 3 Apr 2014 22:45:53 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 774531B8444; Fri, 4 Apr 2014 07:45:48 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 5A0C6180042; Fri, 4 Apr 2014 07:45:48 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 4 Apr 2014 07:45:48 +0200 From: To: "Carlos Pignataro (cpignata)" Date: Fri, 4 Apr 2014 07:45:45 +0200 Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAPxz0AAAlqtgAAFyBhgAAcO/WAABC7E6AADxc+AAAduePw Message-ID: <94C682931C08B048B7A8645303FDC9F36F551AF772@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> <94C682931C08B048B7A8645303FDC9F36F547C7083@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.4.4.42716 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/R-AoWUIpyiCIVc9DVisy0QPPBPw Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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, 04 Apr 2014 05:45:58 -0000 Hi Carlos, I still don't see no answer to my initial question: how that section descri= be the problem or to understand the problem. Your explanation on what the W= G will do is not to be stoned in the document; there are charters for that = purpose.=20 Yes, calling out metadata is an example of a discussion that is close to th= e solution part.=20 My suggestion is to avoid any confusion and scope the document to what it i= s supposed to do. Why such resistance? Cheers, Med >-----Message d'origine----- >De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >Envoy=E9=A0: jeudi 3 avril 2014 16:26 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: Darrel Lewis (darlewis); Tom Nadeau; sfc@ietf.org >Objet=A0: Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >Action: draft-ietf-sfc-problem-statement-03.txt) > >Hi, Med, > >I apologize but I still do not fully understand your point. > >You say: =B3Let us shape a problem statement that is solution-neutral=B2, >which to me seems to imply you believe the problem statement is not >=B3solution-neutral=B2, and you seem to blame Section 3 for that. > >But Section 3 starts by saying: =B3Concretely, the SFC working group will >investigate solutions that address the following elements=B2, and then goe= s >about defining elements, not solutions. The *solutions* that will later >solve the problem defined in this *problem statement* need to address the >*elements* of Section 3. Like I said, it=B9s impossible to describe a >problem without putting names and boundaries to what SFC is (not a >solution). > >We might need to agree to disagree on this... > >Thanks, > >Carlos. > > >-----Original Message----- >From: Med Boucadair >Date: Thursday, April 3, 2014 at 4:37 AM >To: Carlos Pignataro >Cc: "Darrel Lewis (darlewis)" , Tom Nadeau >, "sfc@ietf.org" >Subject: RE: [sfc] Remove Section 3 from the problem statement (was RE: >I-D Action: draft-ietf-sfc-problem-statement-03.txt) > >>Hi Carlos, >> >>Thanks for pointing to these messages. >> >>With all due respect, only the first one you cited tries to motivate the >>need for such section. But the argument you provided does not make sense >>to me, since it is the role of the charter to do that... not to froze >>them in an RFC. >> >>IMHO, the group should be open to any proposal that claim to solve the >>problems listed in the problem statement. >> >>Let us shape a problem statement that is solution-neutral. >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>Envoy=E9 : mercredi 2 avril 2014 21:14 >>>=C0 : BOUCADAIR Mohamed IMT/OLN >>>Cc : Darrel Lewis (darlewis); Tom Nadeau; sfc@ietf.org >>>Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: >>>I-D >>>Action: draft-ietf-sfc-problem-statement-03.txt) >>> >>>Med, >>> >>>Instead of repeating the argument, please see >>>http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>>http://www.ietf.org/mail-archive/web/sfc/current/msg00897.html >>>http://www.ietf.org/mail-archive/web/sfc/current/msg00900.html >>> >>>I would certainly *not* describe Section 3 as an "unbacked framework >>>discussion". By the way, looking at the charter for SFC, the word >>>/framework/i appears exactly zero instances. >>> >>>Best, >>> >>>-- Carlos. >>> >>>On Apr 2, 2014, at 1:45 AM, mohamed.boucadair@orange.com wrote: >>> >>>> Hi Darell, >>>> >>>> That text is not related to the description of the problems; it goes >>>beyond that. That section includes technical points that should be >>>discussed more in a framework document. >>>> >>>> I don't understand why that section is useful to understand the proble= m >>>space. >>>> >>>> I still object packaging a problem statement document with unbacked >>>framework discussion. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>>> Envoy=E9 : mardi 1 avril 2014 20:44 >>>>> =C0 : Thomas Nadeau >>>>> Cc : Darrel Lewis (darlewis); BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>>>> Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE= : >>>I-D >>>>> Action: draft-ietf-sfc-problem-statement-03.txt) >>>>> >>>>> My opinion has not changed, the section seems useful and I see no >>>>>reason >>>it >>>>> should be removed. >>>>> >>>>> -Darrel >>>>> On Apr 1, 2014, at 7:14 AM, Thomas Nadeau >>>wrote: >>>>> >>>>>> >>>>>> This has come up before, and there seemed to be a lot of folks >who >>>>> wanted to leave section 3 in the document, but I will let the chairs >>>make >>>>> the consensus call. >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/sfc/current/msg00896.html >>>>>> >>>>>> --Tom >>>>>> >>>>>> >>>>>> On Apr 1, 2014:7:42 AM, at 7:42 AM, >>>>> wrote: >>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> I raised this point to the co-authors but I prefer to raise it also >>>>>>>in >>>>> the mailing list. >>>>>>> >>>>>>> I suggest to remove Section 3 from the draft >>>>> >>>>>http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section= - >>>3, >>>>> because it goes beyond the problem discussion. That section is more a >>>>> discussion that should be hosted in a framework document. >>>>>>> >>>>>>> Furthermore, some of the points mentioned in that section are >>>>> questionable such as the use of metadata and the need of control >>>protocols, >>>>> etc. Let's avoid mixing objectives and limit the scope of the PS I-D >>>>>to >>>the >>>>> identification to the problems to be solved. >>>>>>> >>>>>>> Aside not, the WG charter is clear about the scope of the PS I-D: >>>>>>> >>>>>>> " >>>>>>> 1. Problem Statement: This document will provide a summary of the >>>>>>> problem space to be addressed by the SFC working group including >>>>>>> example high-level use cases. >>>>>>> " >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de internet- >>>>>>>> drafts@ietf.org >>>>>>>> Envoy=E9 : mardi 1 avril 2014 12:38 >>>>>>>> =C0 : i-d-announce@ietf.org >>>>>>>> Cc : sfc@ietf.org >>>>>>>> Objet : [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >>>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Service Function Chaining Working >>>>> Group >>>>>>>> of the IETF. >>>>>>>> >>>>>>>> Title : Service Function Chaining Problem Statement >>>>>>>> Authors : Paul Quinn >>>>>>>> Thomas Nadeau >>>>>>>> Filename : draft-ietf-sfc-problem-statement-03.txt >>>>>>>> Pages : 18 >>>>>>>> Date : 2014-04-01 >>>>>>>> >>>>>>>> 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 i= s >>>>>>>> used to describe the definition and instantiation of an ordered se= t >>>>>>>> of instances of such service functions, and the subsequent >>>>>>>>"steering" >>>>>>>> of traffic flows through those service functions. >>>>>>>> >>>>>>>> The set of enabled service function chains reflect operator servic= e >>>>>>>> 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-03 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> >>>>>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement= -03 >>>>>>>> >>>>>>>> >>>>>>>> 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/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 nobody Fri Apr 4 05:41: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 4A5BA1A0141 for ; Fri, 4 Apr 2014 05:41:46 -0700 (PDT) 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 FPCg7WCzOoEB for ; Fri, 4 Apr 2014 05:41:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D01A015F for ; Fri, 4 Apr 2014 05:41:41 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id A111A1B83A7 for ; Fri, 4 Apr 2014 14:41:36 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 86F6DC80E2 for ; Fri, 4 Apr 2014 14:41:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 4 Apr 2014 14:41:33 +0200 From: To: "sfc@ietf.org" Date: Fri, 4 Apr 2014 14:41:31 +0200 Thread-Topic: I-D Action: draft-boucadair-sfc-requirements-04.txt Thread-Index: Ac9QAXL/auCF1dBgRJmRkYE/Ve5NKwAAB+MA Message-ID: <94C682931C08B048B7A8645303FDC9F36F551AF942@PUEXCB1B.nanterre.francetelecom.fr> References: <20140404122837.27739.90430.idtracker@ietfa.amsl.com> In-Reply-To: <20140404122837.27739.90430.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.4.4.52715 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/l2yyryiF-CWdXNNHRwDaTq7QZ54 Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Fri, 04 Apr 2014 12:41:46 -0000 Dear all, A new version taking into account the comment received from Dave, Ben, Jim,= and Joel in particular is now available online. The main changes are: * Clarify what is meant by SF loop * Add a definition of SF Spiral * Remove the SF function discovery text 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: vendredi 4 avril 2014 14:29 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-requirements-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Service Function Chaining (SFC) Authors : Mohamed Boucadair Christian Jacquenet Yuanlong Jiang Ron Parker Carlos Pignataro Kengo Naito Filename : draft-boucadair-sfc-requirements-04.txt Pages : 13 Date : 2014-04-04 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-04 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 nobody Fri Apr 4 12:57:36 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 340CE1A01E7 for ; Fri, 4 Apr 2014 12:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 untczuQVNQ6j for ; Fri, 4 Apr 2014 12:57:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC401A00CF for ; Fri, 4 Apr 2014 12:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14964; q=dns/txt; s=iport; t=1396641446; x=1397851046; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nWiSGaEkmkCn9Ruw+EQ8oneDEksugEWtRGal3+cR/ys=; b=S6Fu4P5ss7fXBpOboO+c+9GcVDvuYsmGwheC4OZtcn91hJJ2f48fz4v0 KZ+bxxk0merTpN5QAQhqh0+RmZXixQFoDZAEM9rDMlowbEFjbG2+CUdeX yarY0jd6TEdSdH/72ShodUCnnyCLu0e25GhsgOHqDvNsuIxuefvmZFMUK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAPEHP1OtJA2G/2dsb2JhbABZgwY7UQaDCrlNhzcZgQsWdIIlAQEBBAEBASARMQkEBwwEAgEIEQMBAgECAh8EAwICAiULFAEICAIEDgUJEodeCAWtR6JPF4EpjHEGAQEcMwcGgmmBSQSYW4E0kQuBcYE/gWoIFyI X-IronPort-AV: E=Sophos;i="4.97,796,1389744000"; d="scan'208";a="315160485" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP; 04 Apr 2014 19:57:24 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s34JvNFQ013972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 19:57:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 14:57:23 -0500 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAPxz0AAAlqtgAAFyBhgAAcO/WAABC7E6AADxc+AAAduePwACAnZIA= Date: Fri, 4 Apr 2014 19:57:22 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> <94C682931C08B048B7A8645303FDC9F36F547C7083@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F551AF772@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F551AF772@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: [64.102.157.229] Content-Type: text/plain; charset="utf-8" Content-ID: <06DD8F6B1D732D41B2B8C55E121952F4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9uZNdbLabX10kWTICmc-lRhIze8 Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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, 04 Apr 2014 19:57:35 -0000 SGksIE1lZCwNCg0KVGhlIHdheSB0aGF0IEkgbG9vayBhdCBkcmFmdC1pZXRmLXNmYy1wcm9ibGVt LXN0YXRlbWVudCBpcyB0aGF0IFNlY3Rpb24gMg0KZGVzY3JpYmVzIHByb2JsZW1hdGljIGFzcGVj dHMsIGFuZCBTZWN0aW9uIDMgZGVzY3JpYmVzIGFyZWFzIG9mIGZvY3VzIG9yDQplbGVtZW50cywg Ym90aCBuZWVkZWQgdG8gZGVmaW5lIHRoZSBwcm9ibGVtLiBUaGUgZmlyc3QgaXMgYWJvdXQgY3Vy cmVudA0KcHJvYmxlbXMgdG8gYmUgb3B0aW1pemVkLCB0aGUgc2Vjb25kIGFib3V0IGZ1bmN0aW9u YWwgZWxlbWVudHMuIEJvdGgNCnNlY3Rpb25zIHNheSDigJxTRkMgc2hvdWxkIGludmVzdGlnYXRl IHNvbHV0aW9ucyB0byBhZGRyZXNzIHRoZXNlIFtwcm9ibGVtcw0KYW5kIGFyZWFzXeKAnS4gVGhp cyBpcyBsaWtlbHkgc2ltaWxhciB0byB3aGF0IEkgd3JvdGUgYmVmb3JlIGJ1dCB3aXRoDQpkaWZm ZXJlbnQgd29yZHMuIEkgYXBvbG9naXplIGluIGFkdmFuY2UgaWYgSSBhbSBub3QgY2xlYXIuDQoN CkFyZSB5b3Ugc2F5aW5nIHRoYXQgU0ZDICpzaG91bGQgbm90KiBpbnZlc3RpZ2F0ZSB0aGUgYXJl YXMgbGlzdGVkIGluDQpTZWN0aW9uIDM/DQoNCkxldCBtZSBnaXZlIHlvdSBhbiBleGFtcGxlLCBo b3BpbmcgdGhpcyB3aWxsIGJlIGNsYXJpZnlpbmc6IHRoZSBwcm9ibGVtDQpzdGF0ZW1lbnQgaW4g STJSUzoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy1wcm9ibGVt LXN0YXRlbWVudC0wMA0KDQpTZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1pMnJzLXByb2JsZW0tc3Rh dGVtZW50IGxpc3RzIGEgbW9kZWwgYW5kIHByb2JsZW0NCmFyZWFzLCBldmVuIHJlbGF0aW9uc2hp cHMgb2YgbW9kdWxlcy4gSXMgdGhhdCBhIHNvbHV0aW9uPw0KDQpCZXN0LA0KDQpDYXJsb3MuDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1lZCBCb3VjYWRhaXIgPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpEYXRlOiBGcmlkYXksIEFwcmlsIDQsIDIwMTQgYXQg MTo0NSBBTQ0KVG86IENhcmxvcyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2NvLmNvbT4NCkNjOiAi RGFycmVsIExld2lzIChkYXJsZXdpcykiIDxkYXJsZXdpc0BjaXNjby5jb20+LCBUb20gTmFkZWF1 DQo8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+LCAic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtzZmNdIFJlbW92ZSBTZWN0aW9uIDMgZnJvbSB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQgKHdhcyBSRToNCkktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3Rh dGVtZW50LTAzLnR4dCkNCg0KPkhpIENhcmxvcywNCj4NCj5JIHN0aWxsIGRvbid0IHNlZSBubyBh bnN3ZXIgdG8gbXkgaW5pdGlhbCBxdWVzdGlvbjogaG93IHRoYXQgc2VjdGlvbg0KPmRlc2NyaWJl IHRoZSBwcm9ibGVtIG9yIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0uIFlvdXIgZXhwbGFuYXRp b24gb24NCj53aGF0IHRoZSBXRyB3aWxsIGRvIGlzIG5vdCB0byBiZSBzdG9uZWQgaW4gdGhlIGRv Y3VtZW50OyB0aGVyZSBhcmUNCj5jaGFydGVycyBmb3IgdGhhdCBwdXJwb3NlLg0KPg0KPlllcywg Y2FsbGluZyBvdXQgbWV0YWRhdGEgaXMgYW4gZXhhbXBsZSBvZiBhIGRpc2N1c3Npb24gdGhhdCBp cyBjbG9zZSB0bw0KPnRoZSBzb2x1dGlvbiBwYXJ0Lg0KPg0KPk15IHN1Z2dlc3Rpb24gaXMgdG8g YXZvaWQgYW55IGNvbmZ1c2lvbiBhbmQgc2NvcGUgdGhlIGRvY3VtZW50IHRvIHdoYXQgaXQNCj5p cyBzdXBwb3NlZCB0byBkby4gV2h5IHN1Y2ggcmVzaXN0YW5jZT8NCj4NCj5DaGVlcnMsDQo+TWVk DQo+DQo+Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj5EZSA6IENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCj4+RW52b3nDqSA6IGpl dWRpIDMgYXZyaWwgMjAxNCAxNjoyNg0KPj7DgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4N Cj4+Q2MgOiBEYXJyZWwgTGV3aXMgKGRhcmxld2lzKTsgVG9tIE5hZGVhdTsgc2ZjQGlldGYub3Jn DQo+Pk9iamV0IDogUmU6IFtzZmNdIFJlbW92ZSBTZWN0aW9uIDMgZnJvbSB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQgKHdhcyBSRToNCj4+SS1EDQo+PkFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxl bS1zdGF0ZW1lbnQtMDMudHh0KQ0KPj4NCj4+SGksIE1lZCwNCj4+DQo+PkkgYXBvbG9naXplIGJ1 dCBJIHN0aWxsIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuDQo+Pg0KPj5Zb3Ug c2F5OiDCs0xldCB1cyBzaGFwZSBhIHByb2JsZW0gc3RhdGVtZW50IHRoYXQgaXMgc29sdXRpb24t bmV1dHJhbMKyLA0KPj53aGljaCB0byBtZSBzZWVtcyB0byBpbXBseSB5b3UgYmVsaWV2ZSB0aGUg cHJvYmxlbSBzdGF0ZW1lbnQgaXMgbm90DQo+PsKzc29sdXRpb24tbmV1dHJhbMKyLCBhbmQgeW91 IHNlZW0gdG8gYmxhbWUgU2VjdGlvbiAzIGZvciB0aGF0Lg0KPj4NCj4+QnV0IFNlY3Rpb24gMyBz dGFydHMgYnkgc2F5aW5nOiDCs0NvbmNyZXRlbHksIHRoZSBTRkMgd29ya2luZyBncm91cCB3aWxs DQo+PmludmVzdGlnYXRlIHNvbHV0aW9ucyB0aGF0IGFkZHJlc3MgdGhlIGZvbGxvd2luZyBlbGVt ZW50c8KyLCBhbmQgdGhlbiBnb2VzDQo+PmFib3V0IGRlZmluaW5nIGVsZW1lbnRzLCBub3Qgc29s dXRpb25zLiBUaGUgKnNvbHV0aW9ucyogdGhhdCB3aWxsIGxhdGVyDQo+PnNvbHZlIHRoZSBwcm9i bGVtIGRlZmluZWQgaW4gdGhpcyAqcHJvYmxlbSBzdGF0ZW1lbnQqIG5lZWQgdG8gYWRkcmVzcyB0 aGUNCj4+KmVsZW1lbnRzKiBvZiBTZWN0aW9uIDMuIExpa2UgSSBzYWlkLCBpdMK5cyBpbXBvc3Np YmxlIHRvIGRlc2NyaWJlIGENCj4+cHJvYmxlbSB3aXRob3V0IHB1dHRpbmcgbmFtZXMgYW5kIGJv dW5kYXJpZXMgdG8gd2hhdCBTRkMgaXMgKG5vdCBhDQo+PnNvbHV0aW9uKS4NCj4+DQo+PldlIG1p Z2h0IG5lZWQgdG8gYWdyZWUgdG8gZGlzYWdyZWUgb24gdGhpcy4uLg0KPj4NCj4+VGhhbmtzLA0K Pj4NCj4+Q2FybG9zLg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZy b206IE1lZCBCb3VjYWRhaXIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PkRhdGU6 IFRodXJzZGF5LCBBcHJpbCAzLCAyMDE0IGF0IDQ6MzcgQU0NCj4+VG86IENhcmxvcyBQaWduYXRh cm8gPGNwaWduYXRhQGNpc2NvLmNvbT4NCj4+Q2M6ICJEYXJyZWwgTGV3aXMgKGRhcmxld2lzKSIg PGRhcmxld2lzQGNpc2NvLmNvbT4sIFRvbSBOYWRlYXUNCj4+PHRuYWRlYXVAbHVjaWR2aXNpb24u Y29tPiwgInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRmLm9yZz4NCj4+U3ViamVjdDogUkU6IFtzZmNd IFJlbW92ZSBTZWN0aW9uIDMgZnJvbSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgKHdhcyBSRToNCj4+ SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMudHh0KQ0KPj4N Cj4+PkhpIENhcmxvcywNCj4+Pg0KPj4+VGhhbmtzIGZvciBwb2ludGluZyB0byB0aGVzZSBtZXNz YWdlcy4NCj4+Pg0KPj4+V2l0aCBhbGwgZHVlIHJlc3BlY3QsIG9ubHkgdGhlIGZpcnN0IG9uZSB5 b3UgY2l0ZWQgdHJpZXMgdG8gbW90aXZhdGUgdGhlDQo+Pj5uZWVkIGZvciBzdWNoIHNlY3Rpb24u IEJ1dCB0aGUgYXJndW1lbnQgeW91IHByb3ZpZGVkIGRvZXMgbm90IG1ha2Ugc2Vuc2UNCj4+PnRv IG1lLCBzaW5jZSBpdCBpcyB0aGUgcm9sZSBvZiB0aGUgY2hhcnRlciB0byBkbyB0aGF0Li4uIG5v dCB0byBmcm96ZQ0KPj4+dGhlbSBpbiBhbiBSRkMuDQo+Pj4NCj4+PklNSE8sIHRoZSBncm91cCBz aG91bGQgYmUgb3BlbiB0byBhbnkgcHJvcG9zYWwgdGhhdCBjbGFpbSB0byBzb2x2ZSB0aGUNCj4+ PnByb2JsZW1zIGxpc3RlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+Pj4NCj4+PkxldCB1 cyBzaGFwZSBhIHByb2JsZW0gc3RhdGVtZW50IHRoYXQgaXMgc29sdXRpb24tbmV1dHJhbC4NCj4+ Pg0KPj4+Q2hlZXJzLA0KPj4+TWVkDQo+Pj4NCj4+Pj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4+Pj5EZSA6IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRh QGNpc2NvLmNvbV0NCj4+Pj5FbnZvecOpIDogbWVyY3JlZGkgMiBhdnJpbCAyMDE0IDIxOjE0DQo+ Pj4+w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+Pj4+Q2MgOiBEYXJyZWwgTGV3aXMg KGRhcmxld2lzKTsgVG9tIE5hZGVhdTsgc2ZjQGlldGYub3JnDQo+Pj4+T2JqZXQgOiBSZTogW3Nm Y10gUmVtb3ZlIFNlY3Rpb24gMyBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCAod2FzIFJFOg0K Pj4+PkktRA0KPj4+PkFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMu dHh0KQ0KPj4+Pg0KPj4+Pk1lZCwNCj4+Pj4NCj4+Pj5JbnN0ZWFkIG9mIHJlcGVhdGluZyB0aGUg YXJndW1lbnQsIHBsZWFzZSBzZWUNCj4+Pj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDA4OTYuaHRtbA0KPj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwMDg5Ny5odG1sDQo+Pj4+aHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzAwOTAwLmh0bWwNCj4+ Pj4NCj4+Pj5JIHdvdWxkIGNlcnRhaW5seSAqbm90KiBkZXNjcmliZSBTZWN0aW9uIDMgYXMgYW4g InVuYmFja2VkIGZyYW1ld29yaw0KPj4+PmRpc2N1c3Npb24iLiBCeSB0aGUgd2F5LCBsb29raW5n IGF0IHRoZSBjaGFydGVyIGZvciBTRkMsIHRoZSB3b3JkDQo+Pj4+L2ZyYW1ld29yay9pIGFwcGVh cnMgZXhhY3RseSB6ZXJvIGluc3RhbmNlcy4NCj4+Pj4NCj4+Pj5CZXN0LA0KPj4+Pg0KPj4+Pi0t IENhcmxvcy4NCj4+Pj4NCj4+Pj5PbiBBcHIgMiwgMjAxNCwgYXQgMTo0NSBBTSwgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIERhcmVsbCwNCj4+Pj4+ DQo+Pj4+PiBUaGF0IHRleHQgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIHRo ZSBwcm9ibGVtczsgaXQgZ29lcw0KPj4+PmJleW9uZCB0aGF0LiBUaGF0IHNlY3Rpb24gaW5jbHVk ZXMgdGVjaG5pY2FsIHBvaW50cyB0aGF0IHNob3VsZCBiZQ0KPj4+PmRpc2N1c3NlZCBtb3JlIGlu IGEgZnJhbWV3b3JrIGRvY3VtZW50Lg0KPj4+Pj4NCj4+Pj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3 aHkgdGhhdCBzZWN0aW9uIGlzIHVzZWZ1bCB0byB1bmRlcnN0YW5kIHRoZQ0KPj4+Pj5wcm9ibGVt DQo+Pj4+c3BhY2UuDQo+Pj4+Pg0KPj4+Pj4gSSBzdGlsbCBvYmplY3QgcGFja2FnaW5nIGEgcHJv YmxlbSBzdGF0ZW1lbnQgZG9jdW1lbnQgd2l0aCB1bmJhY2tlZA0KPj4+PmZyYW1ld29yayBkaXNj dXNzaW9uLg0KPj4+Pj4NCj4+Pj4+IENoZWVycywNCj4+Pj4+IE1lZA0KPj4+Pj4NCj4+Pj4+PiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+PiBEZSA6IERhcnJlbCBMZXdpcyAoZGFy bGV3aXMpIFttYWlsdG86ZGFybGV3aXNAY2lzY28uY29tXQ0KPj4+Pj4+IEVudm95w6kgOiBtYXJk aSAxIGF2cmlsIDIwMTQgMjA6NDQNCj4+Pj4+PiDDgCA6IFRob21hcyBOYWRlYXUNCj4+Pj4+PiBD YyA6IERhcnJlbCBMZXdpcyAoZGFybGV3aXMpOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOw0K Pj4+Pj4+c2ZjQGlldGYub3JnDQo+Pj4+Pj4gT2JqZXQgOiBSZTogW3NmY10gUmVtb3ZlIFNlY3Rp b24gMyBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCAod2FzDQo+Pj4+Pj5SRToNCj4+Pj5JLUQN Cj4+Pj4+PiBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAzLnR4dCkN Cj4+Pj4+Pg0KPj4+Pj4+IE15IG9waW5pb24gaGFzIG5vdCBjaGFuZ2VkLCB0aGUgc2VjdGlvbiBz ZWVtcyB1c2VmdWwgYW5kIEkgc2VlIG5vDQo+Pj4+Pj5yZWFzb24NCj4+Pj5pdA0KPj4+Pj4+IHNo b3VsZCBiZSByZW1vdmVkLg0KPj4+Pj4+DQo+Pj4+Pj4gLURhcnJlbA0KPj4+Pj4+IE9uIEFwciAx LCAyMDE0LCBhdCA3OjE0IEFNLCBUaG9tYXMgTmFkZWF1IDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNv bT4NCj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAJVGhpcyBoYXMgY29tZSB1 cCBiZWZvcmUsIGFuZCB0aGVyZSBzZWVtZWQgdG8gYmUgYSBsb3Qgb2YgZm9sa3MNCj4+d2hvDQo+ Pj4+Pj4gd2FudGVkIHRvIGxlYXZlIHNlY3Rpb24gMyBpbiB0aGUgZG9jdW1lbnQsIGJ1dCBJIHdp bGwgbGV0IHRoZSBjaGFpcnMNCj4+Pj5tYWtlDQo+Pj4+Pj4gdGhlIGNvbnNlbnN1cyBjYWxsLg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2Zj L2N1cnJlbnQvbXNnMDA4OTYuaHRtbA0KPj4+Pj4+Pg0KPj4+Pj4+PiAJLS1Ub20NCj4+Pj4+Pj4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gQXByIDEsIDIwMTQ6Nzo0MiBBTSwgYXQgNzo0MiBBTSwgPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+Pj4+Pj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gRGVhciBhbGwsDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gSSByYWlzZWQgdGhpcyBwb2ludCB0byB0aGUgY28tYXV0aG9ycyBidXQgSSBwcmVm ZXIgdG8gcmFpc2UgaXQNCj4+Pj4+Pj4+YWxzbw0KPj4+Pj4+Pj5pbg0KPj4+Pj4+IHRoZSBtYWls aW5nIGxpc3QuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSBzdWdnZXN0IHRvIHJlbW92ZSBTZWN0aW9u IDMgZnJvbSB0aGUgZHJhZnQNCj4+Pj4+Pg0KPj4+Pj4+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMjc2VjdGlvDQo+Pj4+Pj5uLQ0K Pj4+PjMsDQo+Pj4+Pj4gYmVjYXVzZSBpdCBnb2VzIGJleW9uZCB0aGUgcHJvYmxlbSBkaXNjdXNz aW9uLiBUaGF0IHNlY3Rpb24gaXMgbW9yZQ0KPj4+Pj4+YQ0KPj4+Pj4+IGRpc2N1c3Npb24gdGhh dCBzaG91bGQgYmUgaG9zdGVkIGluIGEgZnJhbWV3b3JrIGRvY3VtZW50Lg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IEZ1cnRoZXJtb3JlLCBzb21lIG9mIHRoZSBwb2ludHMgbWVudGlvbmVkIGluIHRoYXQg c2VjdGlvbiBhcmUNCj4+Pj4+PiBxdWVzdGlvbmFibGUgc3VjaCBhcyB0aGUgdXNlIG9mIG1ldGFk YXRhIGFuZCB0aGUgbmVlZCBvZiBjb250cm9sDQo+Pj4+cHJvdG9jb2xzLA0KPj4+Pj4+IGV0Yy4g TGV0J3MgYXZvaWQgbWl4aW5nIG9iamVjdGl2ZXMgYW5kIGxpbWl0IHRoZSBzY29wZSBvZiB0aGUg UFMgSS1EDQo+Pj4+Pj50bw0KPj4+PnRoZQ0KPj4+Pj4+IGlkZW50aWZpY2F0aW9uIHRvIHRoZSBw cm9ibGVtcyB0byBiZSBzb2x2ZWQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQXNpZGUgbm90LCB0aGUg V0cgY2hhcnRlciBpcyBjbGVhciBhYm91dCB0aGUgc2NvcGUgb2YgdGhlIFBTIEktRDoNCj4+Pj4+ Pj4+DQo+Pj4+Pj4+PiAiDQo+Pj4+Pj4+PiAxLiBQcm9ibGVtIFN0YXRlbWVudDogVGhpcyBkb2N1 bWVudCB3aWxsIHByb3ZpZGUgYSBzdW1tYXJ5IG9mIHRoZQ0KPj4+Pj4+Pj4gcHJvYmxlbSBzcGFj ZSB0byBiZSBhZGRyZXNzZWQgYnkgdGhlIFNGQyB3b3JraW5nIGdyb3VwIGluY2x1ZGluZw0KPj4+ Pj4+Pj4gZXhhbXBsZSBoaWdoLWxldmVsIHVzZSBjYXNlcy4NCj4+Pj4+Pj4+ICINCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+PiBNZWQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+Pj4+Pj4gRGUgOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBpbnRlcm5ldC0NCj4+Pj4+Pj4+PiBkcmFm dHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBFbnZvecOpIDogbWFyZGkgMSBhdnJpbCAyMDE0IDEyOjM4 DQo+Pj4+Pj4+Pj4gw4AgOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBDYyA6IHNm Y0BpZXRmLm9yZw0KPj4+Pj4+Pj4+IE9iamV0IDogW3NmY10gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMudHh0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l DQo+Pj4+Pj4+Pj5JbnRlcm5ldC1EcmFmdHMNCj4+Pj4+Pj4+PiBkaXJlY3Rvcmllcy4NCj4+Pj4+ Pj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nDQo+Pj4+Pj4+Pj5Xb3JraW5nDQo+Pj4+Pj4gR3JvdXANCj4+Pj4+Pj4+PiBvZiB0aGUg SUVURi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICBUaXRsZSAgICAgICAgICAgOiBTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nIFByb2JsZW0gU3RhdGVtZW50DQo+Pj4+Pj4+Pj4gICAgIEF1dGhv cnMgICAgICAgICA6IFBhdWwgUXVpbm4NCj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg VGhvbWFzIE5hZGVhdQ0KPj4+Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNm Yy1wcm9ibGVtLXN0YXRlbWVudC0wMy50eHQNCj4+Pj4+Pj4+PiAJUGFnZXMgICAgICAgICAgIDog MTgNCj4+Pj4+Pj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNC0wNC0wMQ0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBv dmVydmlldyBvZiB0aGUgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aA0KPj4+Pj4+Pj4+dGhlDQo+Pj4+ Pj4+Pj4gZGVwbG95bWVudCBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyAoc3VjaCBhcyBmaXJld2FsbHMs IGxvYWQNCj4+Pj4+Pj4+PmJhbGFuY2VycykNCj4+Pj4+Pj4+PiBpbiBsYXJnZS1zY2FsZSBlbnZp cm9ubWVudHMuICBUaGUgdGVybSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nDQo+Pj4+Pj4+Pj5p cw0KPj4+Pj4+Pj4+IHVzZWQgdG8gZGVzY3JpYmUgdGhlIGRlZmluaXRpb24gYW5kIGluc3RhbnRp YXRpb24gb2YgYW4gb3JkZXJlZA0KPj4+Pj4+Pj4+c2V0DQo+Pj4+Pj4+Pj4gb2YgaW5zdGFuY2Vz IG9mIHN1Y2ggc2VydmljZSBmdW5jdGlvbnMsIGFuZCB0aGUgc3Vic2VxdWVudA0KPj4+Pj4+Pj4+ InN0ZWVyaW5nIg0KPj4+Pj4+Pj4+IG9mIHRyYWZmaWMgZmxvd3MgdGhyb3VnaCB0aG9zZSBzZXJ2 aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoZSBzZXQgb2YgZW5hYmxlZCBz ZXJ2aWNlIGZ1bmN0aW9uIGNoYWlucyByZWZsZWN0IG9wZXJhdG9yDQo+Pj4+Pj4+Pj5zZXJ2aWNl DQo+Pj4+Pj4+Pj4gb2ZmZXJpbmdzIGFuZCBpcyBkZXNpZ25lZCBpbiBjb25qdW5jdGlvbiB3aXRo IGFwcGxpY2F0aW9uDQo+Pj4+Pj4+Pj5kZWxpdmVyeQ0KPj4+Pj4+Pj4+IGFuZCBzZXJ2aWNlIGFu ZCBuZXR3b3JrIHBvbGljeS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNm Yy1wcm9ibGVtLXN0YXRlbWVudC8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoZXJlJ3MgYWxzbyBh IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAzDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LQ0KPj4+Pj4+Pj4+MDMNCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4+Pj4+PiBzdWJtaXNzaW9u DQo+Pj4+Pj4+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdA0KPj4+Pj4+Pj4+dG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ Pj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+Pj4+ DQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gc2ZjQGlldGYub3Jn DQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pg0KPg0KDQo= From nobody Fri Apr 4 15:01: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 996161A0168 for ; Fri, 4 Apr 2014 15:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tELQ7yVlb6dA for ; Fri, 4 Apr 2014 15:01:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D52E1A00CA for ; Fri, 4 Apr 2014 15:01:21 -0700 (PDT) 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 BFG98844; Fri, 04 Apr 2014 22:01:09 +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; Fri, 4 Apr 2014 23:00:18 +0100 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; Fri, 4 Apr 2014 23:01:08 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML702-CHM.china.huawei.com ([169.254.4.52]) with mapi id 14.03.0158.001; Fri, 4 Apr 2014 15:00:57 -0700 From: "Louis.Fourie" To: Kevin Glavin , "sfc@ietf.org" Thread-Topic: [sfc] A new proposal on a flexible-length service chain header that is transport independent Thread-Index: AQHPTdRt7RbpZC3Vjk29uEqN8IRF/5r9G2EwgAAYc4CABNLbIA== Date: Fri, 4 Apr 2014 22:00:57 +0000 Message-ID: References: <9EA32E60D7600C43B6FE22876DF564C81D92A718@SFO1EXC-MBXP07.nbttech.com> <9EA32E60D7600C43B6FE22876DF564C81D92ABFC@SFO1EXC-MBXP07.nbttech.com> In-Reply-To: <9EA32E60D7600C43B6FE22876DF564C81D92ABFC@SFO1EXC-MBXP07.nbttech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.109] Content-Type: multipart/alternative; boundary="_000_F50B4ABC6D7E3745BC0AD112C6105A728FAF4FSJCEML703CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IBbb58hMlq8pOQ5detYa0Q6Mj20 Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent 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, 04 Apr 2014 22:01:28 -0000 --_000_F50B4ABC6D7E3745BC0AD112C6105A728FAF4FSJCEML703CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kevin, The proposed TLV format for the in-band transport of metadata for service c= haining is motivated by these reasons: - A service domain will be multi-vendor and there is a need for se= rvice functions offered by different vendors to interoperate in such an environment. The op= tional OUI in the TLV allows for this. - There is a need to identify each item of metadata so that servic= e functions can extract relevant metadata items from the service chain header. - The length field allows service functions that do not recognize = a metadata TLV to skip over that TLV. - The usage of TLVs is optional, so that service chains can be cre= ated using the SCH header without any TLVs. Examples of types of metadata can be found in section 2.2 of the 'Metadata = Considerations' I-D: Examples of such metadata include: o A Subscriber-ID, or more accurately, an Accounting-ID which maps traffic flows to a unique identifier used for accounting and billing purposes. o A Service-Profile-ID and/or Service-Profile-Parameters which identify the service which the Service Functions must apply to the traffic flow. This is discussed in more detail in section 2.4. Others are cited in section 2.4 of the 'SFC Use Cases in Mobile Networks' I= -D: Typical metadata and their sources are: UE: terminal type (e.g., HTC one); IMSI (country, carrier, user); GTP tunnel endpoint: eNB-Identifier; time; PCRF: subscriber info; APN (service name); QoS; policy rules. These are typically of variable length. - Louis From: Kevin Glavin [mailto:Kevin.Glavin@riverbed.com] Sent: Tuesday, April 01, 2014 1:20 PM To: Louis.Fourie; sfc@ietf.org Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header= that is transport independent Thanks Louis, > >Several different examples have been cited, e.g., app-id, subscriber-id, e= tc. >This proposal addresses the need for a flexible method of transporting th= at >metadata that would allow for innovation in the chaining of different ser= vices. It would be a worthwhile exercise to collect concrete examples of each of t= he types that you mentioned and categorize them in terms of size and also i= n terms of potential for simultaneous use. On the size issue: * I suspect that app id < uint32 so in the bigger picture its a non issue h= ow its coded. * If we say (mobile) subscriber-id - how will people expect this to= be used?, a unique u32 id is an option at one end of the spectrum while an= IMEI (16digits), or an MSISDN (15 digits (I think)) is at the other end of= the spectrum. With IMSI being a 64bit number that falls in the middle of t= he spectrum. Fixed encoding suits the short end of the spectrum while TLV suits the lo= nger or variable options, how to do other examples from use cases fall in t= his spectrum? On the issue of potential simultaneous use: My understanding is that SFC is currently targeted at deployments within a = single administrative domain, so the encoded tag only has context within th= at domain. If it only has context within the domain, then you could argue t= hat the context (T) is not providing any information and if the id can be f= ormatted into a fixed length ( L) then all that is interesting is the Value= (V) - taking the position that within an administrative domain a single va= lue namespace with fixed context is all that is needed. To further my questioning, is there a expectation that there will be multip= le independent uses within the same domain, if there is then unique tag id = is important as the same value has the potential to appear in both uses wit= hin the same administrative domain e.g IMEI and MSISDN being used for subsc= riber-id interchangeably. Kevin --_000_F50B4ABC6D7E3745BC0AD112C6105A728FAF4FSJCEML703CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kevin,<= /p>

The proposed TLV format for the in-band transport of= metadata for service chaining

is motivated by these reasons:

 

-       = ;   A service domain will be multi-vendor and there is = a need for service functions

offered by different vendors to interoperate in such= an environment. The optional OUI

in the TLV allows for this.

-       = ;   There is a need to identify each item of metadata s= o that service functions can extract

relevant metadata items from the service chain heade= r.

-       = ;   The length field allows service functions that do n= ot recognize a metadata TLV to

skip over that TLV.

-       = ;   The usage of TLVs is optional, so that service chai= ns can be created using the

SCH header without any TLVs.

 

Examples of types of metadata can be found in sectio= n 2.2 of the ‘Metadata Considerations’ I-D:

 <= /p>

Examples of such metadata include:

 

   o  A Subscriber-ID, or more accurately, = an Accounting-ID which maps

     traffic flows to a unique id= entifier used for accounting and

      billing purposes.

 

   o  A Service-Profile-ID and/or Service-P= rofile-Parameters which

      identify the service which = the Service Functions must apply to

      the traffic flow.  Thi= s is discussed in more detail in section

      2.4.

 <= /p>

Others are cited in section 2.4 of the ‘SFC Us= e Cases in Mobile Networks’ I-D:

 <= /p> 

   Typical metadata and their sources are:
 
   UE:  terminal type (e.g., HTC one); IMSI (country, c=
arrier, user);
 
   GTP tunnel endpoint:  eNB-Identifier; time;
 
   PCRF:  subscriber info; APN (service name); QoS; pol=
icy rules.

 <= /p>

These are typically of variable length.

 

-       = ;   Louis

 

 <= /p>

 <= /p>

From: Kevin Gl= avin [mailto:Kevin.Glavin@riverbed.com]
Sent: Tuesday, April 01, 2014 1:20 PM
To: Louis.Fourie; sfc@ietf.org
Cc: Cathy Zhang
Subject: Re: [sfc] A new proposal on a flexible-length service chain= header that is transport independent

 

Thanks Louis, 

 

> 

>Several different examples have= been cited, e.g., app-id, subscriber-id, etc.

>This proposal  a= ddresses the need for a flexible method of transporting that

>metadata that would a= llow for innovation in the chaining  of different services.

 

 

It would be a worthwhile ex= ercise to collect concrete examples of each of the types that you mentioned= and categorize them in terms of size and also in terms of potential for simultaneous use. 

 

On the size issue:  &n= bsp;

* I suspect that app i= d < uint32 so in the bigger picture its a non issue how its coded. =

       = * If we say (mobile) subscriber-id — how will people expect this to = be used?, a unique u32 id is an option at one end of the spectrum while an = IMEI (16digits), or an MSISDN (15 digits (I think)) is at the other end of the spectrum. Wi= th IMSI being a 64bit number that falls in the middle of the spectrum.=

 

  Fixed encoding = suits the short end of the spectrum while TLV suits the longer or variable = options, how to do other examples from use cases fall in this spectrum?

 

On the issue of potential s= imultaneous use: 

 

My understanding is that SF= C is currently targeted at deployments within a single administrative domai= n, so the encoded tag only has context within that domain. If it only has context within the domain, then you could argue that the co= ntext (T) is not providing any information and if the id can be formatted i= nto a fixed length ( L) then all that is interesting is the Value (V) ̵= 2; taking the position that within an administrative domain a single value namespace with fixed context is all t= hat is needed. 

 

To further my questioning, = is there a expectation that there will be multiple independent uses within = the same domain, if there is then unique tag id is important as the same value has the potential to appear in both uses within the same= administrative domain e.g IMEI and MSISDN being used for subscriber-id int= erchangeably. 

 

Kevin

 

 

--_000_F50B4ABC6D7E3745BC0AD112C6105A728FAF4FSJCEML703CHMchina_-- From nobody Fri Apr 4 15: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 2C6731A022F for ; Fri, 4 Apr 2014 15:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qVQwBy1ckSLb for ; Fri, 4 Apr 2014 15:54:13 -0700 (PDT) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2A091A0225 for ; Fri, 4 Apr 2014 15:54:12 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 04 Apr 2014 15:54:07 -0700 Received: from SFO1EXC-MBXP07.nbttech.com ([fe80::470:1b85:695b:b44e]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%15]) with mapi id 14.02.0328.009; Fri, 4 Apr 2014 15:46:42 -0700 From: Kevin Glavin To: Louis.Fourie , "sfc@ietf.org" Thread-Topic: [sfc] A new proposal on a flexible-length service chain header that is transport independent Thread-Index: AQHPTdRt7RbpZC3Vjk29uEqN8IRF/5r9G2EwgAAYc4CABNLbIIAADSOA Date: Fri, 4 Apr 2014 22:46:41 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D92D2D4@SFO1EXC-MBXP07.nbttech.com> References: <9EA32E60D7600C43B6FE22876DF564C81D92A718@SFO1EXC-MBXP07.nbttech.com> <9EA32E60D7600C43B6FE22876DF564C81D92ABFC@SFO1EXC-MBXP07.nbttech.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.250] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D92D2D4SFO1EXCMBXP07nb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gzAPUzOEIMElDXDCxiHL3RcV7Yc Cc: Cathy Zhang Subject: Re: [sfc] A new proposal on a flexible-length service chain header that is transport independent 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, 04 Apr 2014 22:54:17 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D92D2D4SFO1EXCMBXP07nb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Louis, I have to agree that all these are strong reasons for a TLV approach. Kevin From: "Louis.Fourie" > Date: Friday, April 4, 2014 3:00 PM To: Kevin Glavin >, "sfc@ietf.org" = > Cc: Cathy Zhang > Subject: RE: [sfc] A new proposal on a flexible-length service chain header= that is transport independent Kevin, The proposed TLV format for the in-band transport of metadata for service c= haining is motivated by these reasons: - A service domain will be multi-vendor and there is a need for se= rvice functions offered by different vendors to interoperate in such an environment. The op= tional OUI in the TLV allows for this. - There is a need to identify each item of metadata so that servic= e functions can extract relevant metadata items from the service chain header. - The length field allows service functions that do not recognize = a metadata TLV to skip over that TLV. - The usage of TLVs is optional, so that service chains can be cre= ated using the SCH header without any TLVs. Examples of types of metadata can be found in section 2.2 of the =91Metadat= a Considerations=92 I-D: Examples of such metadata include: o A Subscriber-ID, or more accurately, an Accounting-ID which maps traffic flows to a unique identifier used for accounting and billing purposes. o A Service-Profile-ID and/or Service-Profile-Parameters which identify the service which the Service Functions must apply to the traffic flow. This is discussed in more detail in section 2.4. Others are cited in section 2.4 of the =91SFC Use Cases in Mobile Networks= =92 I-D: Typical metadata and their sources are: UE: terminal type (e.g., HTC one); IMSI (country, carrier, user); GTP tunnel endpoint: eNB-Identifier; time; PCRF: subscriber info; APN (service name); QoS; policy rules. These are typically of variable length. - Louis --_000_9EA32E60D7600C43B6FE22876DF564C81D92D2D4SFO1EXCMBXP07nb_ Content-Type: text/html; charset="Windows-1252" Content-ID: <95094FFF28532241AD59AB337555F352@riverbed.com> Content-Transfer-Encoding: quoted-printable
Louis,&n= bsp;

I have t= o agree that all these are strong reasons for a TLV approach. 

Kevin


From: "Louis.Fourie" <= Louis.Fourie@huawei.com><= br> Date: Friday, April 4, 2014 3:00 PM=
To: Kevin Glavin <kevin.glavin@riverbed.com>, "sfc@ietf.org" <sfc@ietf.org>
Cc: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Subject: RE: [sfc] A new proposal o= n a flexible-length service chain header that is transport independent

Kevin,

The proposed TLV format for the in-band transport of metadata for service c= haining

is motivated by these reasons:

 

-      &= nbsp;   A service domain will be multi-vendor and there= is a need for service functions

offered by different vendors to interoperate in such an environment. The op= tional OUI

in the TLV allows for this.

-      &= nbsp;   There is a need to identify each item of metada= ta so that service functions can extract

relevant metadata items from the service chain header.

-      &= nbsp;   The length field allows service functions that = do not recognize a metadata TLV to

skip over that TLV.

-      &= nbsp;   The usage of TLVs is optional, so that service = chains can be created using the

SCH header without any TLVs.

 

Examples of types of metadata can be found in section 2.2 of the =91Metadat= a Considerations=92 I-D:

 

Examples of s= uch metadata include:

 

   = o  A Subscriber-ID, or more accurately, an Accounting-ID which maps

  &= nbsp;  traffic flows to a unique identifier used for accounting a= nd

  &= nbsp;   billing purposes.

 

   = o  A Service-Profile-ID and/or Service-Profile-Parameters which

  &= nbsp;   identify the service which the Service Functions must app= ly to

  &= nbsp;   the traffic flow.  This is discussed in more detail = in section

  &= nbsp;   2.4.

 

Others are cited in section 2.4 of the =91SFC Use Cases in Mobile Networks= =92 I-D:

 

 &n=
bsp; Typical metadata and their sources are:
&nb=
sp;
 &n=
bsp; UE:  terminal type (e.g., HTC one); IMSI (country, carrier, user)=
;
&nb=
sp;
 &n=
bsp; GTP tunnel endpoint:  eNB-Identifier; time;
&nb=
sp;
 &n=
bsp; PCRF:  subscriber info; APN (service name); QoS; policy rules.

 

These are typically of variable length.

 

-      &= nbsp;   Louis

 

 

 


 

 --_000_9EA32E60D7600C43B6FE22876DF564C81D92D2D4SFO1EXCMBXP07nb_-- From nobody Tue Apr 8 15:27:36 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 F03C71A0755 for ; Tue, 8 Apr 2014 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 hZRffAlLOGhl for ; Tue, 8 Apr 2014 15:27:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B89891A0752 for ; Tue, 8 Apr 2014 15:27:28 -0700 (PDT) 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 BFK47650; Tue, 08 Apr 2014 22:27:28 +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; Tue, 8 Apr 2014 23:26:21 +0100 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; Tue, 8 Apr 2014 23:27:22 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Tue, 8 Apr 2014 15:27:14 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "brijsman@juniper.net" , "jmoisand@juniper.net" , "Ron Parker" Thread-Topic: Comments and suggestions to draft-rijsman-sfc-metadata-considerations Thread-Index: AQHPU3mx4cSkg/v5YEiqtKDVOMGPlA== Date: Tue, 8 Apr 2014 22:27:14 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> In-Reply-To: <53234BF2.5060804@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kHF6PBh6iSmfjBLNXSxXvILqqbw Cc: "sfc@ietf.org" Subject: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 08 Apr 2014 22:27:35 -0000 Bruno and Jerome,=20 I like your analysis of various methods of carrying metadata and their asso= ciated challenges.=20 But some "metadata" mentioned in your draft have been traditionally conside= red as part of policy, as the "20Mbps/30Mbps" used in your Figure 2.=20 Some metadata examples in your draft are specifically passed to service fun= ctions. In many deployment today, Diameter is used to pass those "metadata"= to the service functions.=20 So for those metadata, your analysis on challenges (4.1: metadata-unaware) = are not quite right.=20 I think that we need to have fine-grade names for metadata to make the disc= ussion more accurate and to the point. For example: we should have - Application Layer metadata: those are the metadata exchanged among applic= ations - Service Function layer metadata (or Middleware layer messaging): those ar= e the metadata exchanged among service functions - Metadata exchanged between Service Functions and Network nodes: those are= the metadata exchanged between service functions and network nodes. For e= xample, a DPI function can add a specific "marker" on the packet, so the n= etwork nodes can forward the packet with the policy defined by the "marker"= .=20 With this fine grade metadata, the challenges and the needed network header= extension can be specific and more clearly described.=20 For the "metadata" strictly between applications or between service functio= ns, like the cookies attached to HTTP, today's Proxy Based service function= s can already handle them well. It is debatable if any network header exten= sion is needed for those metadata.=20 For the "metadata" exchanged between Service functions and Network Nodes, t= here is definitely the need for standardized network layer header to carry = those extra information.=20 With those fine grade "metadata", the discussion can be more focused and me= aningful.=20 Linda Dunbar =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, March 14, 2014 1:35 PM To: Ron Parker Cc: sfc@ietf.org Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations If the transport header carries enough information for identifying the sequ= ence (VLAN tag or MPLS label can both do the job), then arguably the global= chain ID is redundant. I can live with carrying it anyway either if I hav= e metadata to carry, or if I need the chain ID for some purpose.=20 After all, some folks seem to want to use that for the forwarding decisio= ns. Yours, Joel On 3/14/14, 2:28 PM, Ron Parker wrote: > The chain ID is the label that defines the sequence of service functions = that must be visited. It can be thought of as a handle for a stack of mus= t-visit network locations. I don't see how this can be anything but manda= tory. > > Ron > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar=20 > (smkumar) > Sent: Friday, March 14, 2014 1:46 PM > To: Joel M. Halpern; NAPIERALA, MARIA H > Cc: sfc@ietf.org > Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations > > [Trimmed the recipient list - needs approval otherwise] > > Completely agree here. > > SFC does not prevent VLAN stitching and one can continue to do that. Whil= e at the same time SFC can include VLAN stitching to support legacy SFs in = the same chain that includes SFC aware SFs. Even legacy SFs benefit from ch= ain identification and hence can be shared across different service chains. > > Surendra. > > > > On 3/14/14 10:26 AM, "Joel M. Halpern" wrote: > >> My own inclination is to observe that if you don't need explicit=20 >> chain identification and you don't need metadata, you can just omit=20 >> the sfc/nsh header. Still do service chaining, just no extra header. >> >> If we are going to have the header, it seems to me that the chain=20 >> identification field is very useful, and low cost once we have the heade= r. >> >> Yours, >> Joel >> >> On 3/14/14, 1:00 PM, NAPIERALA, MARIA H wrote: >>> Explicit chain identification should be made optional. I believe it=20 >>> was discussed few months ago on this mailing list. >>> >>> Maria >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jmh.direct >>> *Sent:* Thursday, March 13, 2014 12:12 PM >>> *To:* kegray@cisco.com; lucy.yong@huawei.com; smkumar@cisco.com;=20 >>> jguichar@cisco.com >>> *Cc:* nicolas.bouthors@qosmos.com; sfc@ietf.org; hadi@mojatatu.com;=20 >>> ron_parker@affirmednetworks.com; brijsman@juniper.net;=20 >>> jmh@joelhalpern.com >>> *Subject:* Re: [sfc] draft-rijsman-sfc-metadata-considerations >>> *Importance:* Low >>> >>> Assuming I understand you properly Ken, I disagree. >>> >>> For example, by using separate terms I can easily discuss the fact=20 >>> that certain kinds of data (chain identification) only need to be=20 >>> adjust by a few apps in rare cases. And that data is not beeded by=20 >>> the applications. >>> >>> Unless you would like to consider the chain identification as being=20 >>> optional? >>> >>> Yours, >>> >>> Joel >>> >>> >>> >>> Sent from my Samsung smartphone on AT&T >>> >>> >>> >>> >>> -------- Original message -------- >>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations >>> From: "Ken Gray (kegray)" >> > >>> To: Lucy yong >> >,"Surendra Kumar (smkumar)" >>> >,"Jim Guichard (jguichar)= " >>> > >>> CC: Nicolas BOUTHORS >> >,sfc >> >,Jamal Hadi Salim >> >,Ron Parker=20 >>> >> >,"brijsman@juniper.net >>> " >> >,"Joel M. Halpern"=20 >>> > >>> >>> The word "metadata" is a purposely ambiguous term "data that=20 >>> provides information about other data". It is used to avoid THIS discu= ssion. >>> >>> For example, I propose we define "tequila metadata" because,=20 >>> frankly, I will need to order a triple-shot if we keep attempting=20 >>> to define something that, by definition, is ambiguous. I'd like my=20 >>> bartender to understand me specifically when I say "I need a shot". >>> >>> On 3/13/14 7:49 AM, "Lucy yong" >> > wrote: >>> >>> >Snip.. >>> >SK> Just copying from the PS: >>> >-- >>> >Data plane metadata provides the ability to exchange information=20 >>> between >>> >the network and service functions, between service functions, and=20 >>> service >>> >functions and the network. >>> > >>> >-- >>> >It is a lucid definition. We are unnecessarily making the word=20 >>> "network" >>> >controversial, IMO. >>> > >>> >[Lucy] This is my point. "The network" is too general here, which=20 >>> brings >>> >metadata great power to do many things. This is why people invent=20 >>> ideas >>> >here, which causes a lot of debates on metadata usage potentials. >>> We >>> >should not spend a lot of times on that debates and judge which=20 >>> usage is >>> >valuable or not. Thus, for the SFC work, it will be helpful if we=20 >>> can >>> >narrow down a bit. Joel makes explicitly two cases, which is=20 >>> helpful to >>> >develop use cases for each case. I would like to see that the=20 >>> problem >>> >statement can be more specific on metadata definition, which may be >>> >helpful in less focusing on it and moving forward. >>> > >>> >Lucy >>> > >>> >Surendra. >>> > >>> > >>> >> >>> >>Thanks, >>> >>Lucy >>> >> >>> >>-----Original Message----- >>> >>From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> >>Sent: Wednesday, March 12, 2014 4:38 PM >>> >>To: Lucy yong >>> >>Cc: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker; >>> >>brijsman@juniper.net ; sfc; Jamal=20 >>> Hadi Salim >>> >>Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations >>> >> >>> >>Hi Lucy, >>> >> >>> >>No. I am simply saying we should not overcomplicate the problem >>> >>statement with text that adds little to no value in my opinion. >>> Whether >>> >>we call it metadata, or context, has no bearing on the fact that=20 >>> the >>> >>problem statement already clearly states we need to be able to=20 >>> pass >>> >>information between SF=B9s and between the network & SF=B9s. >>> >> >>> >> >>> >>On 3/12/14, 5:13 PM, "Lucy yong" >> > wrote: >>> >> >>> >>> >>> >>>Hi Jim, >>> >>> >>> >>>I for one don't agree and think we are over complicating what=20 >>> should >>> >>>be straightforward. The SFC encapsulation should enable two things= : >>> >>> >>> >>>1. Steering of selected flows through a service chain; this is=20 >>> the >>> >>>service function path. >>> >>>2. Passing of context associated with a given flow within said=20 >>> service >>> >>>function path. This context information may be consumed by a SF=20 >>> (an >>> >>>application ID is an example) or may be consumed by the=20 >>> forwarding >>> >>>elements (a vrf-ID is an example). >>> >>>[Lucy] Do you call the context as metadata or not? Do we have=20 >>> another >>> >>>term here beside SFC header and metadata. I see that you don't=20 >>> want to >>> >>>separate what is consumed by SF and what is consumed by the=20 >>> forwarding >>> >>>elements. >>> >>> >>> >>>Lucy >>> >>> >>> >>>Sent from my iPhone >>> >>> >>> >>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong"=20 >>> > wrote: >>> >>>> >>> >>>> Great. Then we may consider two special metadata definitions=20 >>> in the >>> >>>>problem statement so we can all use the same definitions. Here=20 >>> is my >>> >>>>suggested text and like to hear you and other's input and=20 >>> suggestions. >>> >>>> >>> >>>> Dataplane Metadata: Data plane metadata provides the ability to >>> >>>>exchange information between the elements in a service function >>> >>>>chaining. In this context, there are two types of data plane=20 >>> metadata. >>> >>>> >>> >>>> Service Function Metadata: the information exchanged between >>> >>>>classifier and service functions, between service functions to >>> >>>>facilitate service functions on the packet treatment. >>> >>>> >>> >>>> Steering Metadata: the information from service functions to a >>> >>>>classifier or service node for traffic forwarding purpose. >>> >>>> >>> >>>> -end >>> >>>> >>> >>>> Lucy >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> >>>> Sent: Wednesday, March 12, 2014 2:35 PM >>> >>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker >>> >>>> Cc: Jim Guichard (jguichar); brijsman@juniper.net=20 >>> ; sfc; Jamal Hadi >>> >>>> Salim >>> >>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations >>> >>>> >>> >>>> Yes, I am trying to consistently distinguish those two cases=20 >>> when >>> >>>>talking about the information carried with packets in service=20 >>> chains. >>> >>>> >>> >>>> Yours, >>> >>>> Joel >>> >>>> >>> >>>>> On 3/12/14, 3:13 PM, Lucy yong wrote: >>> >>>>> Joel, See below. -----Original Message----- From: sfc >>> >>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent= : >>> >>>>> Wednesday, March 12, 2014 2:02 PM To: Lucy yong; Nicolas=20 >>> BOUTHORS; >>> >>>>> Ron Parker Cc: Jim Guichard (jguichar); brijsman@juniper.net=20 >>> ; sfc; >>> >>>>> Jamal Hadi Salim Subject: Re: [sfc] >>> >>>>> draft-rijsman-sfc-metadata-considerations >>> >>>>> >>> >>>>> I was trying to word it carefully not to focus on who puts the >>> >>>>> information in, but only on who consumes the information. >>> >>>>> Information for service functions may come from the ingress >>> >>>>> classifier or from other service functions. [Lucy] this is=20 >>> the one >>> >>>>> case using metadata in your view. Information for the=20 >>> forwarding >>> >>>>> will generally come from the ingress classifier, but in=20 >>> special >>> >>>>> cases may be provided by service functions. (I keep wanting=20 >>> to get >>> >>>>> rid of those special cases, but so far there seem to be just=20 >>> enough >>> >>>>> of them to warrant covering in the solution. And more=20 >>> importantly, >>> >>>>> significant support for it in the working group.) [Lucy]=20 >>> This is >>> >>>>> the second case using metadata in your view (but you don't=20 >>> like it). >>> >>>>> >>> >>>>> And you suggest distinguishing these two cases when discussing >>> >>>>> about metadata usage. Is that right understanding? >>> >>>>> >>> >>>>> Lucy >>> >>>>> >>> >>>>> Yours, Joel >>> >>>>> >>> >>>>>> On 3/12/14, 2:33 PM, Lucy yong wrote: >>> >>>>>> Joel, I interpret that you suggests that distinguish the=20 >>> exchange >>> >>>>>> information data plane carried between service functions=20 >>> and the >>> >>>>>> exchange information data plane carried from a service=20 >>> function to >>> >>>>>> a service node. Is this right understanding? Lucy >>> >>>>>> >>> >>>>>> -----Original Message----- From: Joel M. Halpern >>> >>>>>> [mailto:jmh@joelhalpern.com] Sent: Wednesday, March 12,=20 >>> 2014 >>> 1:19 >>> >>>>>> PM >>> >>>>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard >>> >>>>>> (jguichar); brijsman@juniper.net=20 >>> ; sfc; Jamal Hadi Salim Subject: >>> >>>>>> Re: [sfc] draft-rijsman-sfc-metadata-considerations >>> >>>>>> >>> >>>>>> My inclination would be to tune that definition to=20 >>> distinguish >>> >>>>>> between dataplane carried information intended for use by=20 >>> service >>> >>>>>> funcitons (whatever the origin), and dataplane carried=20 >>> information >>> >>>>>> intended for dataplane forwarding components. >>> >>>>>> >>> >>>>>> Yours, Joel >>> >>>>>> >>> >>>>>> >>> >>>>>>> Hi Joel, >>> >>>>>>> >>> >>>>>>> I agree that we need using the same definition for a term,=20 >>> but >>> >>>>>>> disagree that the metadata definition here is a set of >>> >>>>>>> information put in the SFC header. This may be too narrow=20 >>> or lead >>> >>>>>>> to a particular solution. I am fine with this definition=20 >>> in the >>> >>>>>>> problem statement w/ minor tweak (suggested on mailing list). >>> >>>>>>> >>> >>>>>>> Dataplane Metadata: Data plane metadata provides the=20 >>> ability to >>> >>>>>>> exchange information between the classifiers and service >>> >>>>>>> functions, between service functions, and service=20 >>> functions and >>> >>>>>>> the >>> >>>>>>> classifiers|service nodes. >>> >>>>>>> >>> >>>>>>> There may be a solution that a service function passes=20 >>> some >>> >>> >>>>>>> information to attached service node without using SFC header= . >>> >>>>>>> >>> >>>>>>> Thanks, Lucy >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> -----Original Message----- From: Joel Halpern Direct >>> >>>>>>> [mailto:jmh.direct@joelhalpern.com] Sent: Wednesday, March=20 >>> 12, >>> >>>>>>> 2014 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas=20 >>> BOUTHORS; >>> >>>>>>> Ron Parker Cc: Jim Guichard (jguichar);=20 >>> brijsman@juniper.net ; >>> >>>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc] >>> >>>>>>> draft-rijsman-sfc-metadata-considerations >>> >>>>>>> >>> >>>>>>> Lucy, you say "the metadata term means ..." The=20 >>> definition you >>> >>>>>>> then provide is a definition of the set of information we=20 >>> are >>> >>>>>>> proposing that we put in the SFC header. I, and others,=20 >>> have >>> >>>>>>> been using the term metadata more narrowly. We can use=20 >>> whatever >>> >>>>>>> definition we want. But we do need to agree on the definition= . >>> >>>>>>> For the purposes of the WG, it seems much more useful to=20 >>> use the >>> >>>>>>> term metadata for the narrower description. >>> >>>>>>> >>> >>>>>>> Yours, Joel >>> >>>>>>> >>> >>>>>>>> On 3/12/14, 1:19 PM, Lucy yong wrote: >>> >>>>>>>> Hi Joel, >>> >>>>>>>> >>> >>>>>>>> I agree. We need to differentiate the metadata used by=20 >>> service >>> >>>>>>>>function and SFC header. The metadata term means carrying=20 >>> some >>> >>>>>>>>states along with the packet. IMO: SFC header is a kind of >>> >>>>>>>>metadata carried on packet for next service node to use.=20 >>> In the >>> >>>>>>>>context of SFC, we have term for SFC header and the=20 >>> metadata that >>> >>>>>>>>was carried between service functions, or between service >>> >>>>>>>>functions and classifiers/service nodes, which is what the=20 >>> draft >>> >>>>>>>>focus. >>> >>>>>>>> >>> >>>>>>>> Thanks, Lucy >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> -----Original Message----- From: Joel M. Halpern >>> >>>>>>>> [mailto:jmh@joelhalpern.com] Sent: Wednesday, March 12, >>> 2014 >>> >>>>>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: >>> Jim >>> >>>>>>>> Guichard (jguichar); brijsman@juniper.net=20 >>> ; sfc; Jamal Hadi Salim >>> >>>>>>>> Subject: Re: [sfc] >>> draft-rijsman-sfc-metadata-considerations >>> >>>>>>>> >>> >>>>>>>> I think it is important to keep a strong distinction=20 >>> between >>> >>>>>>>> metadata (which is for use by applications) and the service >>> >>>>>>>> chaining information in the base service chain header,=20 >>> which is >>> >>>>>>>> for use by the service chain support mechanisms. >>> >>>>>>>> >>> >>>>>>>> Yours, Joel >>> >>>>>>>> >>> >>>>>>>>> On 3/12/14, 10:42 AM, Lucy yong wrote: >>> >>>>>>>>> Fully agree with Joe. >>> >>>>>>>>> >>> >>>>>>>>> We should not require a fix length for in-band metadata=20 >>> but >>> >>>>>>>>> also not leave it for freely usage. In fact, when a=20 >>> service >>> >>>>>>>>> node inserts SFC header on a (encapsulated) packet and=20 >>> send to >>> >>>>>>>>> next service node, SFC header itself can be seen as a=20 >>> metadata. >>> >>>>>>>>> >>> >>>>>>>>> Lucy >>> >>>>>>>>> >>> >>>>>>>>> -----Original Message----- From: sfc >>> >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> >>>>>>>>> Sent: Wednesday, March 12, 2014 9:21 AM To: Nicolas=20 >>> BOUTHORS; >>> >>>>>>>>> Ron Parker Cc: Jim Guichard (jguichar);=20 >>> brijsman@juniper.net ; >>> >>>>>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc] >>> >>>>>>>>> draft-rijsman-sfc-metadata-considerations >>> >>>>>>>>> >>> >>>>>>>>> For in-band metadata, the API for access can easily be >>> >>>>>>>>> synchronous. Out of band metadata needs different handling. >>> >>>>>>>>> There are many cases where out-of-band metadata is=20 >>> useful and >>> >>>>>>>>> appropriate. But they do not cover all needs by any stretc= h. >>> >>>>>>>>> >>> >>>>>>>>> Even if each piece of in-band metadata is of fixed length, >>> >>>>>>>>> there are many different kinds of metatype. Trying to say >>> >>>>>>>>> "there will be exactly four pieces, and they will be of=20 >>> types >>> >>>>>>>>> t1, t2, t3, and t4" is simply too specific for even 80%=20 >>> of the >>> >>>>>>>>>needs. >>> >>>>>>>>> >>> >>>>>>>>> Yours, Joel >>> >>>>>>>>> >>> >>>>>>>>>> On 3/12/14, 8:52 AM, Nicolas BOUTHORS wrote: >>> >>>>>>>>>> Hello Ron, >>> >>>>>>>>>> >>> >>>>>>>>>> Sending out of band congruent metadata may not be the=20 >>> answer >>> >>>>>>>>>> to all needs but it is one tool that we should keep. >>> >>>>>>>>>> >>> >>>>>>>>>> Not all metadata is tied to a specific packet, for=20 >>> example a >>> >>>>>>>>>> policy change in PCRF could lead to some metadata=20 >>> signaling, >>> >>>>>>>>>> the reaction time need not be immediate, few ms may not=20 >>> matter. >>> >>>>>>>>>> >>> >>>>>>>>>> As you point, if a packet is tied to a metadata a=20 >>> correlation >>> >>>>>>>>>> info can be set in both packet to deal with it (i.e=20 >>> metadata >>> >>>>>>>>>> expected flag in the SFC header, plus an id) >>> >>>>>>>>>> >>> >>>>>>>>>> Finally we can still send some limited metadata within=20 >>> a header. >>> >>>>>>>>>> This could be used for load balancers in particular if we >>> >>>>>>>>>> agree on a convention to locate "coarse grain policy" >>> >>>>>>>>>> / "fine grain policy" on reserved context headers. >>> >>>>>>>>>> >>> >>>>>>>>>> This seems to open up a lot of flexibility / innovations. >>> >>>>>>>>>> >>> >>>>>>>>>> On your last point, there is a question on how to make >>> >>>>>>>>>> metadata available to a Service Function. Current socket >>> >>>>>>>>>> connections for example do not allow to retrieve IP=20 >>> header >>> >>>>>>>>>> options. So I assume that SFC aware Service Functions=20 >>> will >>> >>>>>>>>>> need some (asynchronous >>> >>>>>>>>>> ?) API to retrieve SFC header information as well as=20 >>> in-band >>> >>>>>>>>>> metadata. I don't see out of band metadata transport=20 >>> adding >>> >>>>>>>>>> complexity, the same API can probably apply. >>> >>>>>>>>>> >>> >>>>>>>>>> The alternative option, allowing variable sized=20 >>> metadata in >>> >>>>>>>>>> the SFC header has some drawbacks as well, one being >>> >>>>>>>>>> fragmentation, and some switches expecting as well to=20 >>> look at >>> >>>>>>>>>> end user traffic headers for link load balancing. I=20 >>> would >>> >>>>>>>>>> agree that if we can accept these issues, then sending >>> >>>>>>>>>> off-line congruent metadata looses its interest. >>> >>>>>>>>>> >>> >>>>>>>>>> We need to take into account that both in-band and=20 >>> congruent >>> >>>>>>>>>> out-of-band metadata transport is not reliable. A=20 >>> packet loss >>> >>>>>>>>>> triggering retransmission would not lead to the identical >>> >>>>>>>>>> reconstruction of the associated metadata. In some=20 >>> cases, we >>> >>>>>>>>>> might thus even need non-congruent out-of-band reliable >>> >>>>>>>>>> metadata transport. >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> Nicolas ________________________________________ From: >>> Ron >>> >>>>>>>>>> Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, >>> >>>>>>>>>> March 12, 2014 >>> >>>>>>>>>> 12:43 PM To: Nicolas BOUTHORS Cc: Jim Guichard=20 >>> (jguichar); >>> >>>>>>>>>> brijsman@juniper.net ;=20 >>> sfc; Jamal Hadi Salim Subject: Re: [sfc] >>> >>>>>>>>>> draft-rijsman-sfc-metadata-considerations >>> >>>>>>>>>> >>> >>>>>>>>>> Nicolas, >>> >>>>>>>>>> >>> >>>>>>>>>> I understand the concept for out of band signaling of >>> >>>>>>>>>>metadata, but I am concerned that it introduces=20 >>> significant >>> >>>>>>>>>>complexity due to the potential race condition of=20 >>> receiving the >>> >>>>>>>>>>real packet before the metadata. While the real packet=20 >>> could >>> >>>>>>>>>>indicate that out of band metadata is expected, how can we >>> >>>>>>>>>>guarantee the order of reception? What if switching or=20 >>> routing >>> >>>>>>>>>>nodes apply hash based load balancing? What if the load >>> >>>>>>>>>>balancing understands SFC encaps and looks beyond it to=20 >>> the >>> >>>>>>>>>>original header to get better entropy? >>> >>>>>>>>>> Can we guarantee that the metadata and real packet will=20 >>> follow >>> >>>>>>>>>>the exact same path? If we can not, then implementations=20 >>> will >>> >>>>>>>>>>need to add ingress queuing to cope with the scenario. >>> >>>>>>>>>> >>> >>>>>>>>>> Also, do you feel that the increase in implementation >>> >>>>>>>>>> complexity at the service functions is reasonable? >>> >>>>>>>>>> >>> >>>>>>>>>> Thanks. >>> >>>>>>>>>> >>> >>>>>>>>>> Ron >>> >>>>>>>>>> >>> >>>>>>>>>>> On Mar 12, 2014, at 4:09 AM, "Nicolas BOUTHORS" >>> >>>>>>>>>>> >> > wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> I think we must make a distinction between: >>> >>>>>>>>>>> >>> >>>>>>>>>>> - Metadata which should be part of the header defined=20 >>> as in >>> >>>>>>>>>>> band marking. - Metadata with can be passed out of=20 >>> band, for >>> >>>>>>>>>>> example congruent out of band signaling defined in the=20 >>> draft >>> >>>>>>>>>>> >>> >>>>>>>>>>> The former calls for a limited space in the header,=20 >>> true, The >>> >>>>>>>>>>> latter however does not incur any space limitation and=20 >>> is >>> >>>>>>>>>>> still fairly efficient and it remains compatible with=20 >>> a fixed >>> >>>>>>>>>>> size header used to route those signaling messages=20 >>> along the >>> >>>>>>>>>>> chain's service functions. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Nicolas ________________________________________ From: >>> >>>>>>>>>>> Jim Guichard (jguichar) [jguichar@cisco.com] Sent: >>> >>>>>>>>>>> Tuesday, March 11, 2014 6:48 PM To: Ron Parker Cc: >>> >>>>>>>>>>> Nicolas BOUTHORS; brijsman@juniper.net=20 >>> ; sfc; Jamal Hadi Salim >>> >>>>>>>>>>> Subject: Re: [sfc] >>> draft-rijsman-sfc-metadata-considerations >>> >>>>>>>>>>> >>> >>>>>>>>>>> Hi Ron, >>> >>>>>>>>>>> >>> >>>>>>>>>>> We can certainly have this discussion but we should=20 >>> first >>> >>>>>>>>>>> consider what information is necessary and if said >>> >>>>>>>>>>> information can fit within a fixed number of contexts=20 >>> in the >>> >>>>>>>>>>> majority of cases. Remember, the goal of being able to=20 >>> pass >>> >>>>>>>>>>> metadata through the network is to enhance service=20 >>> delivery, >>> >>>>>>>>>>> not pass the entire works of Shakespeare ;-) >>> >>>>>>>>>>> >>> >>>>>>>>>>> Sent from my iPhone >>> >>>>>>>>>>> >>> >>>>>>>>>>>> On Mar 7, 2014, at 3:52 AM, "Ron Parker" >>> >>>>>>>>>>>> >> > wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Nicolas, >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> I see similar requirements from the 3gpp EPC side. I=20 >>> would >>> >>>>>>>>>>>> like to propose an OUI / TLV based approach where the >>> >>>>>>>>>>>> reserved OUI can be used for agreed upon types of=20 >>> common >>> >>>>>>>>>>>> metadata and vendor or other organizational OUIs can=20 >>> be used >>> >>>>>>>>>>>> to quickly innovate in the networks. >>> >>>>>>>>>>>> Simultaneously, I would also like to consider=20 >>> mechanisms >>> >>>>>>>>>>>> that are optimized for long lived flows so as to=20 >>> limit the >>> >>>>>>>>>>>> negative effects of packet growth. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Ron >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> On Mar 7, 2014, at 8:34 AM, "Nicolas BOUTHORS" >>> >>>>>>>>>>>>> >> > wrote: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Hello Jim >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> I have seen cases in Gi LAN, where subscriber related >>> >>>>>>>>>>>>> information is passed to a Web Proxy for HTTP header >>> >>>>>>>>>>>>> enrichment (aimed at some Web Content providers=20 >>> partners of >>> >>>>>>>>>>>>> the Mobile Operator). >>> >>>>>>>>>>>>> Information was an coded (persistent) subscriber id=20 >>> derived >>> >>>>>>>>>>>>> from the MSISDN, and couple of f customer profile=20 >>> related >>> >>>>>>>>>>>>> fields. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> In an sfc based Gi LAN, this entity should receive >> >from the >>> >>>>>>>>>>>>> Classifier >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> - A classification of the Content Provider ( Id, >>> >>>>>>>>>>>>> Category) based on traffic analysis - The MSISDN of=20 >>> the >>> >>>>>>>>>>>>> subscriber - Two subscriber policy fields (not tied=20 >>> to PCRF >>> >>>>>>>>>>>>> but belonging to the Subscriber DB) (Subscriber=20 >>> category, >>> >>>>>>>>>>>>> sub-category) - A session id (for logging and tracking >>> >>>>>>>>>>>>> purposes) >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> The objective being to avoid having the HTTP Proxy to >>> >>>>>>>>>>>>> become a trusted application (interogate the=20 >>> subscriber DB, >>> >>>>>>>>>>>>> etc..) >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Nicolas >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> ________________________________________ From: Jim=20 >>> Guichard >>> >>>>>>>>>>>>> (jguichar) [jguichar@cisco.com] Sent: >>> >>>>>>>>>>>>> Thursday, March 06, 2014 2:02 PM To: Jamal Hadi Salim; >>> >>>>>>>>>>>>> jmoisand@juniper.net ;=20 >>> brijsman@juniper.net Cc: >>> >>>>>>>>>>>>> sfc Subject: Re: [sfc] >>> >>>>>>>>>>>>> draft-rijsman-sfc-metadata-considerations >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Hi Jamal, >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> You said "It seems there's clear need for variable=20 >>> sized >>> >>>>>>>>>>>>> metadata".. I am not so convinced and would like to=20 >>> better >>> >>>>>>>>>>>>> understand the requirements before passing judgement. >>> If we >>> >>>>>>>>>>>>> look at the use cases as presented thus far into the=20 >>> WG I >>> >>>>>>>>>>>>> have yet to see a single example of the need (noting=20 >>> that >>> >>>>>>>>>>>>> desire is not the same as need) - I am not saying=20 >>> there is >>> >>>>>>>>>>>>> no requirement but rather that we should not jump to=20 >>> the >>> >>>>>>>>>>>>> conclusion and build standards around a theory. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>>> On 3/3/14, 6:35 AM, "Jamal Hadi Salim" >>> >>>>>>>>>>>>>> > wrote: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> I like the doc - well written. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Section 4.3 on metadata encoding. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> It seems there's clear need for variable sized=20 >>> metadata >>> >>>>>>>>>>>>>> (at least for http/app you seem to indicate the=20 >>> desire for >>> >>>>>>>>>>>>>>it). >>> >>>>>>>>>>>>>> For a datapath per-packet metadata, i feel the need=20 >>> is >>> >>>>>>>>>>>>>> just as important. Are we limited by the fact that >>> >>>>>>>>>>>>>> existing hardware may not be able to handle TLVs? For >>> >>>>>>>>>>>>>> example, I dont have a problem handling TLVs in a=20 >>> software >>> >>>>>>>>>>>>>>datapath. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> cheers, jamal >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> _______________________________________________ sfc >>> >>>>>>>>>>>>>> mailing list sfc@ietf.org >>> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> _______________________________________________ sfc=20 >>> mailing >>> >>>>>>>>>>>>> list sfc@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ sfc=20 >>> mailing >>> >>>>>>>>>> list sfc@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>>>>>>> >>> >>>>>>>>> _______________________________________________ sfc=20 >>> mailing >>> >>>>>>>>> list sfc@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>>>>>>> >>> >>>>>>>>> _______________________________________________ sfc=20 >>> mailing >>> >>>>>>>>> list sfc@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>>> >>> >>>>> _______________________________________________ sfc mailing=20 >>> list >>> >>>>> sfc@ietf.org =20 >>> 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 > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 8 15:37: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 84EED1A075F for ; Tue, 8 Apr 2014 15:37:14 -0700 (PDT) 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 fA4Q9e81CHB7 for ; Tue, 8 Apr 2014 15:37:11 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 62ECA1A0760 for ; Tue, 8 Apr 2014 15:37:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 82668240155; Tue, 8 Apr 2014 15:37:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (60-250-43-148.HINET-IP.hinet.net [60.250.43.148]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 782CA240A93; Tue, 8 Apr 2014 15:37:10 -0700 (PDT) Message-ID: <53447A13.6000309@joelhalpern.com> Date: Tue, 08 Apr 2014 18:37:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Linda Dunbar , "brijsman@juniper.net" , "jmoisand@juniper.net" , Ron Parker References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RMVebEQJ7lIN-lFVTirUPWy8Yk8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 08 Apr 2014 22:37:14 -0000 Your comment about metadata between service functions being handled today seems to be based on some set of less than obvious assumptions. I do not know of any applicable mechanism today whereby a DPI service function can pass to a content manipulation service function the media type and offset to the content. And that is only one example of many. Even the few cases that are used today are typically done by manipulation of the message content in a fragile fashion. Yours, Joel On 4/8/14, 6:27 PM, Linda Dunbar wrote: > Bruno and Jerome, > > I like your analysis of various methods of carrying metadata and their associated challenges. > > But some "metadata" mentioned in your draft have been traditionally considered as part of policy, as the "20Mbps/30Mbps" used in your Figure 2. > ... > For the "metadata" strictly between applications or between service functions, like the cookies attached to HTTP, today's Proxy Based service functions can already handle them well. It is debatable if any network header extension is needed for those metadata. > > For the "metadata" exchanged between Service functions and Network Nodes, there is definitely the need for standardized network layer header to carry those extra information. > ... From nobody Tue Apr 8 18:13: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 813181A0758 for ; Tue, 8 Apr 2014 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 onpapr-WYqmw for ; Tue, 8 Apr 2014 18:13:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 227FB1A0735 for ; Tue, 8 Apr 2014 18:13:11 -0700 (PDT) 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 BFK55866; Wed, 09 Apr 2014 01:13:11 +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, 9 Apr 2014 02:12:09 +0100 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; Wed, 9 Apr 2014 02:13:10 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Tue, 8 Apr 2014 18:12:56 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "brijsman@juniper.net" , "jmoisand@juniper.net" , "Ron Parker" Thread-Topic: Comments and suggestions to draft-rijsman-sfc-metadata-considerations Thread-Index: AQHPU3mx4cSkg/v5YEiqtKDVOMGPlJsIxImA//+zIHA= Date: Wed, 9 Apr 2014 01:12:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF1B35@dfweml701-chm.china.huawei.com> References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> <53447A13.6000309@joelhalpern.com> In-Reply-To: <53447A13.6000309@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.152.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QF0eWdPxeFz-lQXJIMYfgbATcrE Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 09 Apr 2014 01:13:14 -0000 Joel,=20 Today's proxy based service functions terminate TCP session and restart the= TCP session to the next service function or the destination of the packet.= Some of them attach data/cookies to the packet.=20 All those are strictly between service functions.=20 I didn't say anything about "DPI service function passing to a content mani= pulation service function the media type and offset to the content".=20 There have been proposals (not at IETF yet) for having a fixed header field= in data packets for a service function to insert some marker (or identifie= r) for network nodes to steer the packet without looking deeper into the pa= ckets, or vise versa. Those metadata between "service function" and "networ= k node" should be the one that requires Metadata standardization.=20 Yours,=20 Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, April 08, 2014 5:37 PM To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to draft-rijsman-sfc-metadata-conside= rations Your comment about metadata between service functions being handled today s= eems to be based on some set of less than obvious assumptions. I do not kn= ow of any applicable mechanism today whereby a DPI service function can pas= s to a content manipulation service function the media type and offset to t= he content. And that is only one example of many. Even the few cases that are used today are typically done by manipulation o= f the message content in a fragile fashion. Yours, Joel On 4/8/14, 6:27 PM, Linda Dunbar wrote: > Bruno and Jerome, > > I like your analysis of various methods of carrying metadata and their as= sociated challenges. > > But some "metadata" mentioned in your draft have been traditionally consi= dered as part of policy, as the "20Mbps/30Mbps" used in your Figure 2. > ... > For the "metadata" strictly between applications or between service funct= ions, like the cookies attached to HTTP, today's Proxy Based service functi= ons can already handle them well. It is debatable if any network header ext= ension is needed for those metadata. > > For the "metadata" exchanged between Service functions and Network Nodes,= there is definitely the need for standardized network layer header to carr= y those extra information. > ... From nobody Wed Apr 9 05:17: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 412241A020A for ; Wed, 9 Apr 2014 05:17:27 -0700 (PDT) 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 p6z0REpgj_ah for ; Wed, 9 Apr 2014 05:17:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 847B81A01AC for ; Wed, 9 Apr 2014 05:17:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1DD70240B47; Wed, 9 Apr 2014 05:17:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (60-250-43-148.HINET-IP.hinet.net [60.250.43.148]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D4375240A49; Wed, 9 Apr 2014 05:17:22 -0700 (PDT) Message-ID: <53453A51.4030404@joelhalpern.com> Date: Wed, 09 Apr 2014 08:17:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Linda Dunbar , "brijsman@juniper.net" , "jmoisand@juniper.net" , Ron Parker References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> <53447A13.6000309@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1B35@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CF1B35@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IAO9qwjO-CAAoCAA3B4hLRWx2SY Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 09 Apr 2014 12:17:27 -0000 Maybe I am misreading your notes. The first part of your reply seems to say that there are existing techniques by which some service functions can pass data on to some other service functions. That is true. That does not mean that the range of needs is addressed. You even seem to acknowledge that. You then go on to say that we should only address the other problem (metadata between service functions and network nodes). Given that a large part of the problem of carrying metadata between service functions is not addressed currently, I do not see why we should neglect addressing that major problem. Yours, Joel On 4/8/14, 9:12 PM, Linda Dunbar wrote: > > Joel, > > Today's proxy based service functions terminate TCP session and > restart the TCP session to the next service function or the > destination of the packet. Some of them attach data/cookies to the > packet. > > All those are strictly between service functions. > > I didn't say anything about "DPI service function passing to a > content manipulation service function the media type and offset to > the content". > > There have been proposals (not at IETF yet) for having a fixed header > field in data packets for a service function to insert some marker > (or identifier) for network nodes to steer the packet without looking > deeper into the packets, or vise versa. Those metadata between > "service function" and "network node" should be the one that requires > Metadata standardization. > > Yours, > > Linda > > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron > Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to > draft-rijsman-sfc-metadata-considerations > > Your comment about metadata between service functions being handled > today seems to be based on some set of less than obvious assumptions. > I do not know of any applicable mechanism today whereby a DPI service > function can pass to a content manipulation service function the > media type and offset to the content. And that is only one example > of many. > > Even the few cases that are used today are typically done by > manipulation of the message content in a fragile fashion. > > Yours, Joel > > On 4/8/14, 6:27 PM, Linda Dunbar wrote: >> Bruno and Jerome, >> >> I like your analysis of various methods of carrying metadata and >> their associated challenges. >> >> But some "metadata" mentioned in your draft have been traditionally >> considered as part of policy, as the "20Mbps/30Mbps" used in your >> Figure 2. >> > ... >> For the "metadata" strictly between applications or between service >> functions, like the cookies attached to HTTP, today's Proxy Based >> service functions can already handle them well. It is debatable if >> any network header extension is needed for those metadata. >> >> For the "metadata" exchanged between Service functions and Network >> Nodes, there is definitely the need for standardized network layer >> header to carry those extra information. >> > ... > From nobody Wed Apr 9 07:48: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 89FE91A030F for ; Wed, 9 Apr 2014 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 BmDuXdw9rV8G for ; Wed, 9 Apr 2014 07:48:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 32F871A0297 for ; Wed, 9 Apr 2014 07:48:26 -0700 (PDT) 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 BFL27158; Wed, 09 Apr 2014 14:48:25 +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; Wed, 9 Apr 2014 15:47:08 +0100 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; Wed, 9 Apr 2014 15:48:23 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Wed, 9 Apr 2014 07:48:18 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "brijsman@juniper.net" , "jmoisand@juniper.net" , "Ron Parker" Thread-Topic: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations Thread-Index: AQHPU3mx4cSkg/v5YEiqtKDVOMGPlJsIxImA//+zIHCAATIMgP//sPDg Date: Wed, 9 Apr 2014 14:48:18 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF2076@dfweml701-chm.china.huawei.com> References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> <53447A13.6000309@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1B35@dfweml701-chm.china.huawei.com> <53453A51.4030404@joelhalpern.com> In-Reply-To: <53453A51.4030404@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.172] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NcpnejyTZIdf6ztWE5gWsLwZ2BU Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 09 Apr 2014 14:48:31 -0000 Joel,=20 Comments inserted inline below: -----Original Message----- The first part of your reply seems to say that there are existing technique= s by which some service functions can pass data on to some other service fu= nctions. That is true. That does not mean that the range of needs is addr= essed. You even seem to acknowledge that. [Linda] Do you think the information exchange between service functions are= relevant to routing? Shouldn't those metadata be transparent to network no= des? You then go on to say that we should only address the other problem (metada= ta between service functions and network nodes). [Linda] Because I think those metadata are relevant to network layer and ro= uting.=20 Given that a large part of the problem of carrying metadata between service= functions is not addressed currently, I do not see why we should neglect a= ddressing that major problem. Yours, Joel On 4/8/14, 9:12 PM, Linda Dunbar wrote: > > Joel, > > Today's proxy based service functions terminate TCP session and=20 > restart the TCP session to the next service function or the=20 > destination of the packet. Some of them attach data/cookies to the=20 > packet. > > All those are strictly between service functions. > > I didn't say anything about "DPI service function passing to a content=20 > manipulation service function the media type and offset to the=20 > content". > > There have been proposals (not at IETF yet) for having a fixed header=20 > field in data packets for a service function to insert some marker (or=20 > identifier) for network nodes to steer the packet without looking=20 > deeper into the packets, or vise versa. Those metadata between=20 > "service function" and "network node" should be the one that requires=20 > Metadata standardization. > > Yours, > > Linda > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=20 > Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to=20 > draft-rijsman-sfc-metadata-considerations > > Your comment about metadata between service functions being handled=20 > today seems to be based on some set of less than obvious assumptions. > I do not know of any applicable mechanism today whereby a DPI service=20 > function can pass to a content manipulation service function the media=20 > type and offset to the content. And that is only one example of many. > > Even the few cases that are used today are typically done by=20 > manipulation of the message content in a fragile fashion. > > Yours, Joel > > On 4/8/14, 6:27 PM, Linda Dunbar wrote: >> Bruno and Jerome, >> >> I like your analysis of various methods of carrying metadata and=20 >> their associated challenges. >> >> But some "metadata" mentioned in your draft have been traditionally=20 >> considered as part of policy, as the "20Mbps/30Mbps" used in your=20 >> Figure 2. >> > ... >> For the "metadata" strictly between applications or between service=20 >> functions, like the cookies attached to HTTP, today's Proxy Based=20 >> service functions can already handle them well. It is debatable if=20 >> any network header extension is needed for those metadata. >> >> For the "metadata" exchanged between Service functions and Network=20 >> Nodes, there is definitely the need for standardized network layer=20 >> header to carry those extra information. >> > ... > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 9 23:10: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 720841A00D8 for ; Wed, 9 Apr 2014 23:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 NekYueHAro6m for ; Wed, 9 Apr 2014 23:10:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9C1A00D1 for ; Wed, 9 Apr 2014 23:10:18 -0700 (PDT) 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 BFL86477; Thu, 10 Apr 2014 06:10:16 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 07:08:59 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 07:10:15 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 14:10:11 +0800 From: "Songhaibin (A)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-song-sfc-legacy-sf-mapping-00.txt Thread-Index: AQHPVF3R+LFq7YvWoEeDgekah7UhcpsKXB5Q Date: Thu, 10 Apr 2014 06:10:10 +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.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TWHPxz2m1KUOJwyfmyrUlzZ0bzc Subject: [sfc] FW: New Version Notification for draft-song-sfc-legacy-sf-mapping-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, 10 Apr 2014 06:10:22 -0000 SGkgZ3V5cywNCg0KV2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciBsZWdhY3kgc2Vy dmljZSBmdW5jdGlvbiBzdXBwb3J0LiBUaGUgbW90aXZhdGlvbiBpcyB0aGF0IGxlZ2FjeSBzZXJ2 aWNlIGZ1bmN0aW9ucyBjYW4gcGFydGljaXBhdGUgaW4gU0ZDLCBidXQgdGhleSBkbyBub3QgdW5k ZXJzdGFuZCBTRkMgaGVhZGVyLiBTZXJ2aWNlIEZvcndhcmRpbmcgRW5naW5lIGlzIHJlc3BvbnNp YmxlIGZvciBkZWNhcHN1bGF0aW5nIHRoZSBTRkMgaGVhZGVyIGxvY2FsbHksIHNlbmRpbmcgdGhl IHBhY2tldCB0byBsZWdhY3kgU0ZJLCBhbmQgdGhlbiBlbmNhcHN1bGF0aW5nIHRoZSBTRkMgaGVh ZGVyIGFmdGVyIHJlY2VpdmluZyB0aGUgcmV0dXJuZWQgcGFja2V0LiBNZWNoYW5pc21zIGZvciBt YXBwaW5nIHRoZSBTRkMgaGVhZGVyIHRvIHNvbWUgZmllbGQgb2YgdGhlIHBhY2tldCBoYXZlIGJl ZW4gcHJvcG9zZWQuIA0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMC50eHQNCg0KQW55IGNvbW1lbnRzIGFyZSBh cHByZWNpYXRlZCENCg0KQmVzdCBSZWdhcmRzIQ0KLUhhaWJpbg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTAsIDIw MTQgOTo0MCBBTQ0KPiBUbzogU29uZ2hhaWJpbiAoQSk7IEx1Y3kgeW9uZzsgU29uZ2hhaWJpbiAo QSk7IEx1Y3kgeW9uZzsgSmlhbmd5dWFubG9uZzsNCj4gSmlhbmd5dWFubG9uZw0KPiBTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1t YXBwaW5nLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zb25n LXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBIYWliaW4gU29uZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRv cnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmcNCj4gUmV2 aXNpb246CTAwDQo+IFRpdGxlOgkJU0ZDIEhlYWRlciBNYXBwaW5nIGZvciBMZWdhY3kgU0YNCj4g RG9jdW1lbnQgZGF0ZToJMjAxNC0wNC0xMA0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lv bg0KPiBQYWdlczoJCTEwDQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmctMDAudHh0DQo+IFN0YXR1czoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29uZy1zZmMtbGVnYWN5 LXNmLW1hcHBpbmcvDQo+IEh0bWxpemVkOg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0K PiAgICBTRkMgKFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcpIGlzIHVzZWQgdG8gbWFuaXB1bGF0 ZSBzZXJ2aWNlDQo+ICAgIGZ1bmN0aW9ucyB3aXRoIGVhc3kgY3JlYXRpb24sIHVwZGF0aW5nIGFu ZCBkZWxldGlvbi4gIEEgc2VydmljZQ0KPiAgICBmdW5jdGlvbiBjaGFpbiBnb2VzIHRocm91Z2gg YSBsaXN0IG9mIG9yZGVyZWQgc2VydmljZSBmdW5jdGlvbg0KPiAgICBpbnN0YW5jZXMuICBPbmUg YXNzdW1wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGlzIHRoYXQgbGVnYWN5IHNlcnZpY2UNCj4gICAg ZnVuY3Rpb24gaW5zdGFuY2VzIGNhbiBwYXJ0aWNpcGF0ZSBpbiB0aGUgc2VydmljZSBjaGFpbi4g IFRoZXkgYXJlDQo+ICAgIG5vdCBhd2FyZSBvZiB0aGUgU0ZDIGhlYWRlciwgbm9yIGludGVycHJl dCBpdC4gIFRoaXMgZG9jdW1lbnQNCj4gICAgcHJvdmlkZXMgYSBtZWNoYW5pc20gYmV0d2VlbiBh IFNlcnZpY2UgRm9yd2FyZGluZyBFbnRpdHkgKFNGRSkgYW5kIGENCj4gICAgU2VydmljZSBGdW5j dGlvbiBJbnN0YW5jZSAoU0ZJKSwgdG8gaWRlbnRpZnkgdGhlIFNGQyBoZWFkZXINCj4gICAgYXNz b2NpYXRlZCB3aXRoIGEgcGFja2V0IHRoYXQgaXMgcmV0dXJuZWQgZnJvbSBhbiBTRkksIHdpdGhv dXQgU0ZDDQo+ICAgIGhlYWRlciBiZWluZyBleHBsaWNpdGx5IGNhcnJpZWQgaW4gdGhlIHdpcmVk IHByb3RvY29sIGJldHdlZW4gU0ZFIGFuZA0KPiAgICBTRkkuDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Thu Apr 10 06:17: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 E2C2B1A01C1 for ; Thu, 10 Apr 2014 06:17:12 -0700 (PDT) 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, 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 eqj0nc5zp2s2 for ; Thu, 10 Apr 2014 06:17:08 -0700 (PDT) Received: from mc28.lon.server.colt.net (mc28.lon.server.colt.net [212.74.77.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6AE1A012D for ; Thu, 10 Apr 2014 06:17:08 -0700 (PDT) Received: from mc28.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 10B10F00CF for ; Thu, 10 Apr 2014 13:16:36 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc28.lon.server.colt.net (Postfix) with ESMTP id DDB2FF00CC for ; Thu, 10 Apr 2014 13:16:35 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,834,1389740400"; d="scan'208";a="959841" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 10 Apr 2014 15:16:35 +0200 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([10.12.1.3]) with mapi id 14.01.0438.000; Thu, 10 Apr 2014 15:16:34 +0200 From: Nicolas BOUTHORS To: "Joel M. Halpern" , Linda Dunbar , "brijsman@juniper.net" , "jmoisand@juniper.net" , Ron Parker Thread-Topic: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations Thread-Index: AQHPVLz0edmSLP0G+UWFjF0hvUtFmw== Date: Thu, 10 Apr 2014 13:16:34 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D43C3D1@LILAS.jungle.qosmos.com> References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> <53447A13.6000309@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1B35@dfweml701-chm.china.huawei.com>, <53453A51.4030404@joelhalpern.com> In-Reply-To: <53453A51.4030404@joelhalpern.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1017-20622.007 X-TM-AS-Result: No--14.181-5.0-31-10 X-imss-scan-details: No--14.181-5.0-31-10 X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1017-20622.007 X-TMASE-Result: 10--14.180700-5.000000 X-TMASE-MatchedRID: TmlY9+XBoTlf8szgSbttgrMjW/sniEQK6w8SgVGmO15XopZjyO6CZepU Olu1Vn8QeLprPHGTqJaN2PAB92r10p7oe7OF0U2W020eWoALA9el9VzHf0qr7n7VDimCjmLfrW4 1+BBqq+/OUYb9lgqQ3eE7RoOCJMelx25lXUKnIFdHFWsq1vzd1CwvdvzdTlpZkZfWHaYX33qgLL LilQBEN83UBwUAhFx/c3OQ9zX5ApdGPqvMHhkuCv9Ci025qU0x0i/hFXziUdPJC2Vrkbq/8SNrW gSEdSwg8bJb0aNG//92C9GksEU5sPlXbaRPf/X2yf21YeIsPYYj1/mVULk89Kq9wgXVNwtgRPUQ QiicYfRQApag86cfvJCpuMCLs2Gh6G/4VXa7516mQhbcat5/fVHewY36PuY0AXpARVn7fDwGhyL tK9BH7I2hehDyrUy26FitcwONFSkYXTzhQbz/ZGh77jTUbA6yYLTkznvC2b/fUZT83lbkEEwcYS eZPOpjOzFXSAl+fMWbu+FyWYBKSkOrZJUSTvYoVnRXm1iHN1bEQdG7H66TyH4gKq42LRYkEVAfV Uli3EUTQPAafZwO7AQkkvZNeObxECeu0hQcnuh+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KEnb4OhSILr1PDCfACi1GU8-Ztg Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 10 Apr 2014 13:17:13 -0000 Hello=0A= =0A= I can see the benefit, as shown by Linda, to distinguish how to convey meta= data according to which function =0A= will benefit from its use. =0A= =0A= The metadata draft from Bruno shows many possibilities. At the same time, t= here are discussions on =0A= how intelligent/flexible a SFF should/could be. I think an Openflow based S= FF for example could=0A= provide added value, provided it finds in the SFC header enough information= .=0A= =0A= A fixed size header can carry a number of information allowing Service Swit= ching Functions to take local =0A= decision on how to handle incoming or outgoing traffic. I share with Linda = the feeling that an application Id =0A= field and a fine grain policy field, will enable innovation compared to a = header opaque or without any =0A= metadata. =0A= =0A= Congruent metadata messages are a good complement to send information from = one SF or another one, =0A= There are ways to allow SF to retrieve this information, just as there are = ways for SF to retreive out of band =0A= metadata. In both cases, the metadata messages are not constrained in size,= and some standard format =0A= exists already to carry similar information. =0A= =0A= =0A= Nicolas=0A= ________________________________________=0A= From: Joel M. Halpern [jmh@joelhalpern.com]=0A= Sent: Wednesday, April 09, 2014 2:17 PM=0A= To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron Parker=0A= Cc: sfc@ietf.org=0A= Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-c= onsiderations=0A= =0A= Maybe I am misreading your notes.=0A= =0A= The first part of your reply seems to say that there are existing=0A= techniques by which some service functions can pass data on to some=0A= other service functions. That is true. That does not mean that the=0A= range of needs is addressed. You even seem to acknowledge that.=0A= =0A= You then go on to say that we should only address the other problem=0A= (metadata between service functions and network nodes).=0A= =0A= Given that a large part of the problem of carrying metadata between=0A= service functions is not addressed currently, I do not see why we should=0A= neglect addressing that major problem.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 4/8/14, 9:12 PM, Linda Dunbar wrote:=0A= >=0A= > Joel,=0A= >=0A= > Today's proxy based service functions terminate TCP session and=0A= > restart the TCP session to the next service function or the=0A= > destination of the packet. Some of them attach data/cookies to the=0A= > packet.=0A= >=0A= > All those are strictly between service functions.=0A= >=0A= > I didn't say anything about "DPI service function passing to a=0A= > content manipulation service function the media type and offset to=0A= > the content".=0A= >=0A= > There have been proposals (not at IETF yet) for having a fixed header=0A= > field in data packets for a service function to insert some marker=0A= > (or identifier) for network nodes to steer the packet without looking=0A= > deeper into the packets, or vise versa. Those metadata between=0A= > "service function" and "network node" should be the one that requires=0A= > Metadata standardization.=0A= >=0A= > Yours,=0A= >=0A= > Linda=0A= >=0A= >=0A= > -----Original Message----- From: Joel M. Halpern=0A= > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM=0A= > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=0A= > Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to=0A= > draft-rijsman-sfc-metadata-considerations=0A= >=0A= > Your comment about metadata between service functions being handled=0A= > today seems to be based on some set of less than obvious assumptions.=0A= > I do not know of any applicable mechanism today whereby a DPI service=0A= > function can pass to a content manipulation service function the=0A= > media type and offset to the content. And that is only one example=0A= > of many.=0A= >=0A= > Even the few cases that are used today are typically done by=0A= > manipulation of the message content in a fragile fashion.=0A= >=0A= > Yours, Joel=0A= >=0A= > On 4/8/14, 6:27 PM, Linda Dunbar wrote:=0A= >> Bruno and Jerome,=0A= >>=0A= >> I like your analysis of various methods of carrying metadata and=0A= >> their associated challenges.=0A= >>=0A= >> But some "metadata" mentioned in your draft have been traditionally=0A= >> considered as part of policy, as the "20Mbps/30Mbps" used in your=0A= >> Figure 2.=0A= >>=0A= > ...=0A= >> For the "metadata" strictly between applications or between service=0A= >> functions, like the cookies attached to HTTP, today's Proxy Based=0A= >> service functions can already handle them well. It is debatable if=0A= >> any network header extension is needed for those metadata.=0A= >>=0A= >> For the "metadata" exchanged between Service functions and Network=0A= >> Nodes, there is definitely the need for standardized network layer=0A= >> header to carry those extra information.=0A= >>=0A= > ...=0A= >=0A= =0A= =0A= From nobody Thu Apr 10 10:05: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 958B51A0309 for ; Thu, 10 Apr 2014 10:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 ywTBq8LHE7l9 for ; Thu, 10 Apr 2014 10:05:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id E1A611A02FD for ; Thu, 10 Apr 2014 10:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4339; q=dns/txt; s=iport; t=1397149540; x=1398359140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BdK/cDTR6VlpMKYnhSOnRt9I/zGJ7TlZdPWC4rqSTwQ=; b=DKq4Mos3l0jYNc4SY6+f+oWhz3KRpKOCqLYwnIvccgVL6Nd9wpwzWp+6 y36yHo7/3gRWzOKPTAl9K7kRBPH1MeRAGsw08BJxC5ycWvJCw6iWujw43 cKwMFdnS43Ta2JGb2FD9VYhyfy9qAnSSI4GMqOrlPyuSCVGOjvmHOyK0w M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAFvORlOtJA2G/2dsb2JhbABagwY7V7xxhzWBIxZ0giUBAQEEAQEBNzQLDAQCAQgRBAEBAR4JBycLFAkIAgQBDQWHfA3NOxMEjmwHBoQyAQOYXpJCgzCCKw X-IronPort-AV: E=Sophos;i="4.97,835,1389744000"; d="scan'208";a="34731893" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 10 Apr 2014 17:05:39 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3AH5dwt009821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 17:05:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 12:05:39 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar , "Joel M. Halpern" , "brijsman@juniper.net" , "jmoisand@juniper.net" , Ron Parker Thread-Topic: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations Thread-Index: AQHPU5Dnzf47u7k+xkamy+WOISQfaJsJiACAgAAqLACAAXWlgA== Date: Thu, 10 Apr 2014 17:05:38 +0000 Message-ID: References: <9wpek1o9cwfd51qatfhe1o82.1394727128188@email.android.com> <1D70D757A2C9D54D83B4CBD7625FA80E0135C7C6@MISOUT7MSGUSR9I.ITServices.sbc.com> <53233BDA.8070903@joelhalpern.com> <53234BF2.5060804@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1A31@dfweml701-chm.china.huawei.com> <53447A13.6000309@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF1B35@dfweml701-chm.china.huawei.com> <53453A51.4030404@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645CF2076@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CF2076@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.21.149.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <3BE3684C862ED946ADC2CD2F813C08AC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qUnnS9W8fAS9Ol4uLMiD0EOoreI Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations 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, 10 Apr 2014 17:05:45 -0000 A few in lines of my own ... On 4/9/14 10:48 AM, "Linda Dunbar" wrote: >Joel,=20 > >Comments inserted inline below: > >-----Original Message----- > > >The first part of your reply seems to say that there are existing >techniques by which some service functions can pass data on to some other >service functions. That is true. That does not mean that the range of >needs is addressed. You even seem to acknowledge that. > >[Linda] Do you think the information exchange between service functions >are relevant to routing? Shouldn't those metadata be transparent to >network nodes? {Ken} - I don't recall any text saying the network nodes (assuming you mean the infrastructure here) HAS to parse the metadata. > > >You then go on to say that we should only address the other problem >(metadata between service functions and network nodes). > >[Linda] Because I think those metadata are relevant to network layer and >routing. {Ken} - not only did this seem contradictory to your proposal for separation of the two, I'm super curious how you see service function metadata being relevant to routing (keeping in mind that the non-metadata part of the header has a path info imbedded). >=20 > > >Given that a large part of the problem of carrying metadata between >service functions is not addressed currently, I do not see why we should >neglect addressing that major problem. > >Yours, >Joel > >On 4/8/14, 9:12 PM, Linda Dunbar wrote: >> >> Joel, >> >> Today's proxy based service functions terminate TCP session and >> restart the TCP session to the next service function or the >> destination of the packet. Some of them attach data/cookies to the >> packet. >> >> All those are strictly between service functions. >> >> I didn't say anything about "DPI service function passing to a content >> manipulation service function the media type and offset to the >> content". >> >> There have been proposals (not at IETF yet) for having a fixed header >> field in data packets for a service function to insert some marker (or >> identifier) for network nodes to steer the packet without looking >> deeper into the packets, or vise versa. Those metadata between >> "service function" and "network node" should be the one that requires >> Metadata standardization. >> >> Yours, >> >> Linda >> >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM >> To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron >> Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to >> draft-rijsman-sfc-metadata-considerations >> >> Your comment about metadata between service functions being handled >> today seems to be based on some set of less than obvious assumptions. >> I do not know of any applicable mechanism today whereby a DPI service >> function can pass to a content manipulation service function the media >> type and offset to the content. And that is only one example of many. >> >> Even the few cases that are used today are typically done by >> manipulation of the message content in a fragile fashion. >> >> Yours, Joel >> >> On 4/8/14, 6:27 PM, Linda Dunbar wrote: >>> Bruno and Jerome, >>> >>> I like your analysis of various methods of carrying metadata and >>> their associated challenges. >>> >>> But some "metadata" mentioned in your draft have been traditionally >>> considered as part of policy, as the "20Mbps/30Mbps" used in your >>> Figure 2. >>> >> ... >>> For the "metadata" strictly between applications or between service >>> functions, like the cookies attached to HTTP, today's Proxy Based >>> service functions can already handle them well. It is debatable if >>> any network header extension is needed for those metadata. >>> >>> For the "metadata" exchanged between Service functions and Network >>> Nodes, there is definitely the need for standardized network layer >>> header to carry those extra information. >>> >> ... >> > >_______________________________________________ >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 nobody Thu Apr 10 17:46: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 C76B61A03DD; Thu, 10 Apr 2014 17:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 DncAjNVg7EZl; Thu, 10 Apr 2014 17:46:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id CA44E1A03D3; Thu, 10 Apr 2014 17:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6236; q=dns/txt; s=iport; t=1397177176; x=1398386776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ldvdGd24ZjXXgyttcyMMOFaIcNInC2Z2GHfnuWr7YNE=; b=XfOWAh46KXMwyBxoLDsO66J+Li1BV4f7tl7Q54s+qCfx4Abb3hRXuVY9 mmbS2q/IrUh5Ciia39UcfFuwxgbB08N8HY99GYlFk2vd36YVzuyoKhL9M 4jgPtsDLA4TuRvF8YwzyPRzpXHKP8IyPCxfX+sxlPs4id17cN62lKgBvr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAKE6R1OtJA2H/2dsb2JhbABagwY7UQa9AYc1gR4WdIIlAQEBAwEBAQFiCQsFBwQCAQgRAQMBASgHJwsUAwYIAgQOBQmHawgIBcxEF445MwcGgx6BFASYXoE1kQ2DMIIr X-IronPort-AV: E=Sophos;i="4.97,837,1389744000"; d="scan'208";a="34820946" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP; 11 Apr 2014 00:46:15 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3B0kFIb023635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 00:46:15 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 19:46:15 -0500 From: "Paul Quinn (paulq)" To: Lucy yong Thread-Topic: [sfc] comments RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt Thread-Index: AQHPTduCx9O4DUWfNUqYcSxbthbLOpsL9vwA Date: Fri, 11 Apr 2014 00:46:14 +0000 Message-ID: References: <20140401103734.19995.31059.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D4536C144@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4536C144@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.19.17.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zP0iAVtt7d0r06UZEO2EVXYdKTw Cc: "internet-drafts@ietf.org" , "sfc@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [sfc] comments RE: I-D Action: draft-ietf-sfc-problem-statement-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, 11 Apr 2014 00:46:23 -0000 Hi Lucy, Thank you for your comments. As you know this document is going to be nearing last call, so we (the edit= ors) are being very careful with any changes going forward and need to ensu= re WG concensus. Having said that I have some comments and questions for the WG below. Thanks, Paul On Apr 1, 2014, at 2:51 PM, Lucy yong wrote: > Here are some comments on this version. >=20 > 1) The term of Classification entity is used in section 3.4 without defin= ing it. IMO: it is good for us to treat this entity as a special SF and add= the text in 3.3 to clarify that. The specialty is that the entity selects = the traffic entering a service overlay compared to other SFs receives the t= raffic from service overlay. >=20 PQ> Perhaps a clarifying term: =93SFC classifier=94 and define it as a log= ical component of the architecture. By defining it as logical, it can take= any implementation form required: distinct separate node, integrated into = a network node, or into a service function. =20 > 2) Text in abstraction: The set of enabled service function chains reflec= t operator service offerings and is designed in conjunction with applicatio= n delivery and service and network policy. >=20 > Suggested text: Text in abstraction: The set of enabled service function = chains reflect operator service offerings and are designed in conjunction w= ith application delivery, service, and network policy. PQ> Typo: =93is=94 =97> =93are=94, will be corrected. =20 >=20 > 3) Text in 3.1 :=20 >=20 > Service function chaining utilizes a service specific overlay that > creates the service topology. The service overlay provides service > function connectivity and is built "on top" of the existing network > topology and allows operators to use whatever overlay or underlay > they prefer to create a path between service functions, and to locate > service functions in the network as needed. >=20 > Suggested Text: =20 >=20 > Service function chaining utilizes a service overlay that > creates the service topology. The service overlay provides service > function connectivity and is built "on top" of the existing network > topologies. SFC allows operators to use whatever overlay or underlay > to create a path between a service function and service node, service n= odes,=20 > and to locate service functions in the existing networks as needed. >=20 > 4) Text in 3.4 >=20 > Data plane metadata provides the ability to exchange information > between classification entities and service functions, between > service functions, service functions and classification entities and > service nodes, and as such does not provide forwarding information > used to deliver packet along the service overlay. >=20 > Metadata can include the result of antecedent classification, > information from external sources or forwarding related data. > Service functions utilize metadata, as required, for localized policy > decisions. >=20 > Comments: two paragraphs are conflict. Need to be fixed. If a classificat= ion entity can be seen as a special SF, it can be easily fixed. >=20 PQ> I=92m not sure there=92s a conflict, but perhaps the text can be update= d to reflect the proposed defn of classifier and to clarify if the WG deems= appropriate: Data plane metadata provides the ability to exchange information between SFC classifiers and service functions (and vice versa) and betwee= n service functions. As such is not used as forwarding information to deli= ver packet along the service overlay. =20 Metadata can include the result of antecedent classification and/or information from external sources. Service functions utilize metadata, a= s required, for localized policy decisions. > Thanks, > Lucy >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org > Sent: Tuesday, April 01, 2014 5:38 AM > To: i-d-announce@ietf.org > Cc: sfc@ietf.org > Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Service Function Chaining Working Group = of the IETF. >=20 > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-03.txt > Pages : 18 > Date : 2014-04-01 >=20 > 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 instances of such service functions, and the subsequent "steering" > of traffic flows through those service functions. >=20 > The set of enabled service function chains reflect operator service > offerings and is designed in conjunction with application delivery > and service and network policy. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-03 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 nobody Thu Apr 10 23:30: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 B6FF21A03FB for ; Thu, 10 Apr 2014 23:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 lCHIbkQcW5df for ; Thu, 10 Apr 2014 23:30:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 93AD41A03C6 for ; Thu, 10 Apr 2014 23:30:16 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 116E818C5B7; Fri, 11 Apr 2014 08:30:15 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DCF7D35C048; Fri, 11 Apr 2014 08:30:14 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 11 Apr 2014 08:30:14 +0200 From: To: "Carlos Pignataro (cpignata)" Date: Fri, 11 Apr 2014 08:30:12 +0200 Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9Nn3Ewj0+n9hDOSXOVuZTJi4/0WgAPxz0AAAlqtgAAFyBhgAAcO/WAABC7E6AADxc+AAAduePwACAnZIABQaMEQA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F551B06F5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <0C48A6DC-76B1-4F38-A8B0-E1F4A61E4008@lucidvision.com> <260A9567-D62C-402E-8579-206A0662CC16@cisco.com> <94C682931C08B048B7A8645303FDC9F36F54484BA5@PUEXCB1B.nanterre.francetelecom.fr> <99E5F358-A1A2-4396-892B-61297B352F66@cisco.com> <94C682931C08B048B7A8645303FDC9F36F547C7083@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F551AF772@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.10.105120 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XGlTIzoQ6nxUDavzlKLI9MSUOK0 Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" , Tom Nadeau Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-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, 11 Apr 2014 06:30:20 -0000 SGkgQ2FybG9zLA0KDQpXaGF0IEknbSBzYXlpbmcgaXM6IHdoYXQgc2hvdWxkIGJlIGludmVzdGln YXRlZCBieSB0aGUgV0cgaXMgdG8gYmUgY2FwdHVyZWQgaW4gYSBjaGFydGVyIG5vdCBpbiBhbiBS RkMuIA0KDQpUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2hvdWxkIG5vdCBiZSBib3VuZCB0byBzb21l IHJlYXNvbmluZyB0aGF0IG1heSBiZSBvYnNvbGV0ZSBpbiB0aGUgZnV0dXJlIHdoaWxlIHRoZSBw cm9ibGVtcyBtYXkgc3RpbGwgYmUgdGhlcmUgZXZlbiB3aXRoIHRoZSBzb2x1dGlvbiBmbGF2b3Jz IHdlIGhhdmUgb24gdGhlIHRhYmxlIHRvZGF5LiBJIHByb3ZpZGVkIGFuIGV4YW1wbGUgaW4gYW5v dGhlciB0aHJlYWQgd2hlcmUgSSdtIHRhbGtpbmcgYWJvdXQgaGlkZGVuIGNvbXBsZXhpdHkgb2Yg ZHluYW1pYyBTRkMgb3IgdGhlIGNvbXBsaWNhdGlvbnMgcmVsYXRlZCB0byBjbGFzc2lmaWNhdGlv biBlbnRyaWVzIG1hbmFnZW1lbnQsIGNyb3NzLWxheWVyIGRpYWdub3NpcyBhbmQgdHJvdWJsZXNo b290aW5nLCBldGMuDQoNCkNoZWVycywNCk1lZA0KDQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+RGXCoDogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFA Y2lzY28uY29tXQ0KPkVudm95w6nCoDogdmVuZHJlZGkgNCBhdnJpbCAyMDE0IDIxOjU3DQo+w4DC oDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPkNjwqA6IERhcnJlbCBMZXdpcyAoZGFybGV3 aXMpOyBUb20gTmFkZWF1OyBzZmNAaWV0Zi5vcmcNCj5PYmpldMKgOiBSZTogW3NmY10gUmVtb3Zl IFNlY3Rpb24gMyBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCAod2FzIFJFOiBJLUQNCj5BY3Rp b246IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAzLnR4dCkNCj4NCj5IaSwgTWVk LA0KPg0KPlRoZSB3YXkgdGhhdCBJIGxvb2sgYXQgZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0 ZW1lbnQgaXMgdGhhdCBTZWN0aW9uIDINCj5kZXNjcmliZXMgcHJvYmxlbWF0aWMgYXNwZWN0cywg YW5kIFNlY3Rpb24gMyBkZXNjcmliZXMgYXJlYXMgb2YgZm9jdXMgb3INCj5lbGVtZW50cywgYm90 aCBuZWVkZWQgdG8gZGVmaW5lIHRoZSBwcm9ibGVtLiBUaGUgZmlyc3QgaXMgYWJvdXQgY3VycmVu dA0KPnByb2JsZW1zIHRvIGJlIG9wdGltaXplZCwgdGhlIHNlY29uZCBhYm91dCBmdW5jdGlvbmFs IGVsZW1lbnRzLiBCb3RoDQo+c2VjdGlvbnMgc2F5IOKAnFNGQyBzaG91bGQgaW52ZXN0aWdhdGUg c29sdXRpb25zIHRvIGFkZHJlc3MgdGhlc2UgW3Byb2JsZW1zDQo+YW5kIGFyZWFzXeKAnS4gVGhp cyBpcyBsaWtlbHkgc2ltaWxhciB0byB3aGF0IEkgd3JvdGUgYmVmb3JlIGJ1dCB3aXRoDQo+ZGlm ZmVyZW50IHdvcmRzLiBJIGFwb2xvZ2l6ZSBpbiBhZHZhbmNlIGlmIEkgYW0gbm90IGNsZWFyLg0K Pg0KPkFyZSB5b3Ugc2F5aW5nIHRoYXQgU0ZDICpzaG91bGQgbm90KiBpbnZlc3RpZ2F0ZSB0aGUg YXJlYXMgbGlzdGVkIGluDQo+U2VjdGlvbiAzPw0KPg0KPkxldCBtZSBnaXZlIHlvdSBhbiBleGFt cGxlLCBob3BpbmcgdGhpcyB3aWxsIGJlIGNsYXJpZnlpbmc6IHRoZSBwcm9ibGVtDQo+c3RhdGVt ZW50IGluIEkyUlM6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMnJz LXByb2JsZW0tc3RhdGVtZW50LTAwDQo+DQo+U2VjdGlvbiAyIG9mIGRyYWZ0LWlldGYtaTJycy1w cm9ibGVtLXN0YXRlbWVudCBsaXN0cyBhIG1vZGVsIGFuZCBwcm9ibGVtDQo+YXJlYXMsIGV2ZW4g cmVsYXRpb25zaGlwcyBvZiBtb2R1bGVzLiBJcyB0aGF0IGEgc29sdXRpb24/DQo+DQo+QmVzdCwN Cj4NCj5DYXJsb3MuDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBN ZWQgQm91Y2FkYWlyIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPkRhdGU6IEZyaWRh eSwgQXByaWwgNCwgMjAxNCBhdCAxOjQ1IEFNDQo+VG86IENhcmxvcyBQaWduYXRhcm8gPGNwaWdu YXRhQGNpc2NvLmNvbT4NCj5DYzogIkRhcnJlbCBMZXdpcyAoZGFybGV3aXMpIiA8ZGFybGV3aXNA Y2lzY28uY29tPiwgVG9tIE5hZGVhdQ0KPjx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4sICJzZmNA aWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+DQo+U3ViamVjdDogUkU6IFtzZmNdIFJlbW92ZSBTZWN0 aW9uIDMgZnJvbSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgKHdhcyBSRToNCj5JLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wMy50eHQpDQo+DQo+PkhpIENhcmxvcywN Cj4+DQo+Pkkgc3RpbGwgZG9uJ3Qgc2VlIG5vIGFuc3dlciB0byBteSBpbml0aWFsIHF1ZXN0aW9u OiBob3cgdGhhdCBzZWN0aW9uDQo+PmRlc2NyaWJlIHRoZSBwcm9ibGVtIG9yIHRvIHVuZGVyc3Rh bmQgdGhlIHByb2JsZW0uIFlvdXIgZXhwbGFuYXRpb24gb24NCj4+d2hhdCB0aGUgV0cgd2lsbCBk byBpcyBub3QgdG8gYmUgc3RvbmVkIGluIHRoZSBkb2N1bWVudDsgdGhlcmUgYXJlDQo+PmNoYXJ0 ZXJzIGZvciB0aGF0IHB1cnBvc2UuDQo+Pg0KPj5ZZXMsIGNhbGxpbmcgb3V0IG1ldGFkYXRhIGlz IGFuIGV4YW1wbGUgb2YgYSBkaXNjdXNzaW9uIHRoYXQgaXMgY2xvc2UgdG8NCj4+dGhlIHNvbHV0 aW9uIHBhcnQuDQo+Pg0KPj5NeSBzdWdnZXN0aW9uIGlzIHRvIGF2b2lkIGFueSBjb25mdXNpb24g YW5kIHNjb3BlIHRoZSBkb2N1bWVudCB0byB3aGF0IGl0DQo+PmlzIHN1cHBvc2VkIHRvIGRvLiBX aHkgc3VjaCByZXNpc3RhbmNlPw0KPj4NCj4+Q2hlZXJzLA0KPj5NZWQNCj4+DQo+Pj4tLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+PkRlIDogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp IFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPj4+RW52b3nDqSA6IGpldWRpIDMgYXZyaWwg MjAxNCAxNjoyNg0KPj4+w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+Pj5DYyA6IERh cnJlbCBMZXdpcyAoZGFybGV3aXMpOyBUb20gTmFkZWF1OyBzZmNAaWV0Zi5vcmcNCj4+Pk9iamV0 IDogUmU6IFtzZmNdIFJlbW92ZSBTZWN0aW9uIDMgZnJvbSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQg KHdhcyBSRToNCj4+PkktRA0KPj4+QWN0aW9uOiBkcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRl bWVudC0wMy50eHQpDQo+Pj4NCj4+PkhpLCBNZWQsDQo+Pj4NCj4+PkkgYXBvbG9naXplIGJ1dCBJ IHN0aWxsIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuDQo+Pj4NCj4+PllvdSBz YXk6IMKzTGV0IHVzIHNoYXBlIGEgcHJvYmxlbSBzdGF0ZW1lbnQgdGhhdCBpcyBzb2x1dGlvbi1u ZXV0cmFswrIsDQo+Pj53aGljaCB0byBtZSBzZWVtcyB0byBpbXBseSB5b3UgYmVsaWV2ZSB0aGUg cHJvYmxlbSBzdGF0ZW1lbnQgaXMgbm90DQo+Pj7Cs3NvbHV0aW9uLW5ldXRyYWzCsiwgYW5kIHlv dSBzZWVtIHRvIGJsYW1lIFNlY3Rpb24gMyBmb3IgdGhhdC4NCj4+Pg0KPj4+QnV0IFNlY3Rpb24g MyBzdGFydHMgYnkgc2F5aW5nOiDCs0NvbmNyZXRlbHksIHRoZSBTRkMgd29ya2luZyBncm91cCB3 aWxsDQo+Pj5pbnZlc3RpZ2F0ZSBzb2x1dGlvbnMgdGhhdCBhZGRyZXNzIHRoZSBmb2xsb3dpbmcg ZWxlbWVudHPCsiwgYW5kIHRoZW4gZ29lcw0KPj4+YWJvdXQgZGVmaW5pbmcgZWxlbWVudHMsIG5v dCBzb2x1dGlvbnMuIFRoZSAqc29sdXRpb25zKiB0aGF0IHdpbGwgbGF0ZXINCj4+PnNvbHZlIHRo ZSBwcm9ibGVtIGRlZmluZWQgaW4gdGhpcyAqcHJvYmxlbSBzdGF0ZW1lbnQqIG5lZWQgdG8gYWRk cmVzcyB0aGUNCj4+PiplbGVtZW50cyogb2YgU2VjdGlvbiAzLiBMaWtlIEkgc2FpZCwgaXTCuXMg aW1wb3NzaWJsZSB0byBkZXNjcmliZSBhDQo+Pj5wcm9ibGVtIHdpdGhvdXQgcHV0dGluZyBuYW1l cyBhbmQgYm91bmRhcmllcyB0byB3aGF0IFNGQyBpcyAobm90IGENCj4+PnNvbHV0aW9uKS4NCj4+ Pg0KPj4+V2UgbWlnaHQgbmVlZCB0byBhZ3JlZSB0byBkaXNhZ3JlZSBvbiB0aGlzLi4uDQo+Pj4N Cj4+PlRoYW5rcywNCj4+Pg0KPj4+Q2FybG9zLg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBNZWQgQm91Y2FkYWlyIDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPg0KPj4+RGF0ZTogVGh1cnNkYXksIEFwcmlsIDMsIDIwMTQgYXQgNDozNyBBTQ0K Pj4+VG86IENhcmxvcyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2NvLmNvbT4NCj4+PkNjOiAiRGFy cmVsIExld2lzIChkYXJsZXdpcykiIDxkYXJsZXdpc0BjaXNjby5jb20+LCBUb20gTmFkZWF1DQo+ Pj48dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+LCAic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3Jn Pg0KPj4+U3ViamVjdDogUkU6IFtzZmNdIFJlbW92ZSBTZWN0aW9uIDMgZnJvbSB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQgKHdhcyBSRToNCj4+PkktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLXByb2Js ZW0tc3RhdGVtZW50LTAzLnR4dCkNCj4+Pg0KPj4+PkhpIENhcmxvcywNCj4+Pj4NCj4+Pj5UaGFu a3MgZm9yIHBvaW50aW5nIHRvIHRoZXNlIG1lc3NhZ2VzLg0KPj4+Pg0KPj4+PldpdGggYWxsIGR1 ZSByZXNwZWN0LCBvbmx5IHRoZSBmaXJzdCBvbmUgeW91IGNpdGVkIHRyaWVzIHRvIG1vdGl2YXRl IHRoZQ0KPj4+Pm5lZWQgZm9yIHN1Y2ggc2VjdGlvbi4gQnV0IHRoZSBhcmd1bWVudCB5b3UgcHJv dmlkZWQgZG9lcyBub3QgbWFrZSBzZW5zZQ0KPj4+PnRvIG1lLCBzaW5jZSBpdCBpcyB0aGUgcm9s ZSBvZiB0aGUgY2hhcnRlciB0byBkbyB0aGF0Li4uIG5vdCB0byBmcm96ZQ0KPj4+PnRoZW0gaW4g YW4gUkZDLg0KPj4+Pg0KPj4+PklNSE8sIHRoZSBncm91cCBzaG91bGQgYmUgb3BlbiB0byBhbnkg cHJvcG9zYWwgdGhhdCBjbGFpbSB0byBzb2x2ZSB0aGUNCj4+Pj5wcm9ibGVtcyBsaXN0ZWQgaW4g dGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KPj4+Pg0KPj4+PkxldCB1cyBzaGFwZSBhIHByb2JsZW0g c3RhdGVtZW50IHRoYXQgaXMgc29sdXRpb24tbmV1dHJhbC4NCj4+Pj4NCj4+Pj5DaGVlcnMsDQo+ Pj4+TWVkDQo+Pj4+DQo+Pj4+Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+Pj5EZSA6 IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0N Cj4+Pj4+RW52b3nDqSA6IG1lcmNyZWRpIDIgYXZyaWwgMjAxNCAyMToxNA0KPj4+Pj7DgCA6IEJP VUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4+Pj4+Q2MgOiBEYXJyZWwgTGV3aXMgKGRhcmxld2lz KTsgVG9tIE5hZGVhdTsgc2ZjQGlldGYub3JnDQo+Pj4+Pk9iamV0IDogUmU6IFtzZmNdIFJlbW92 ZSBTZWN0aW9uIDMgZnJvbSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgKHdhcyBSRToNCj4+Pj4+SS1E DQo+Pj4+PkFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMudHh0KQ0K Pj4+Pj4NCj4+Pj4+TWVkLA0KPj4+Pj4NCj4+Pj4+SW5zdGVhZCBvZiByZXBlYXRpbmcgdGhlIGFy Z3VtZW50LCBwbGVhc2Ugc2VlDQo+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9zZmMvY3VycmVudC9tc2cwMDg5Ni5odG1sDQo+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwMDg5Ny5odG1sDQo+Pj4+Pmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwMDkwMC5odG1sDQo+ Pj4+Pg0KPj4+Pj5JIHdvdWxkIGNlcnRhaW5seSAqbm90KiBkZXNjcmliZSBTZWN0aW9uIDMgYXMg YW4gInVuYmFja2VkIGZyYW1ld29yaw0KPj4+Pj5kaXNjdXNzaW9uIi4gQnkgdGhlIHdheSwgbG9v a2luZyBhdCB0aGUgY2hhcnRlciBmb3IgU0ZDLCB0aGUgd29yZA0KPj4+Pj4vZnJhbWV3b3JrL2kg YXBwZWFycyBleGFjdGx5IHplcm8gaW5zdGFuY2VzLg0KPj4+Pj4NCj4+Pj4+QmVzdCwNCj4+Pj4+ DQo+Pj4+Pi0tIENhcmxvcy4NCj4+Pj4+DQo+Pj4+Pk9uIEFwciAyLCAyMDE0LCBhdCAxOjQ1IEFN LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBIaSBE YXJlbGwsDQo+Pj4+Pj4NCj4+Pj4+PiBUaGF0IHRleHQgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIGRl c2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtczsgaXQgZ29lcw0KPj4+Pj5iZXlvbmQgdGhhdC4gVGhh dCBzZWN0aW9uIGluY2x1ZGVzIHRlY2huaWNhbCBwb2ludHMgdGhhdCBzaG91bGQgYmUNCj4+Pj4+ ZGlzY3Vzc2VkIG1vcmUgaW4gYSBmcmFtZXdvcmsgZG9jdW1lbnQuDQo+Pj4+Pj4NCj4+Pj4+PiBJ IGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoYXQgc2VjdGlvbiBpcyB1c2VmdWwgdG8gdW5kZXJzdGFu ZCB0aGUNCj4+Pj4+PnByb2JsZW0NCj4+Pj4+c3BhY2UuDQo+Pj4+Pj4NCj4+Pj4+PiBJIHN0aWxs IG9iamVjdCBwYWNrYWdpbmcgYSBwcm9ibGVtIHN0YXRlbWVudCBkb2N1bWVudCB3aXRoIHVuYmFj a2VkDQo+Pj4+PmZyYW1ld29yayBkaXNjdXNzaW9uLg0KPj4+Pj4+DQo+Pj4+Pj4gQ2hlZXJzLA0K Pj4+Pj4+IE1lZA0KPj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K Pj4+Pj4+PiBEZSA6IERhcnJlbCBMZXdpcyAoZGFybGV3aXMpIFttYWlsdG86ZGFybGV3aXNAY2lz Y28uY29tXQ0KPj4+Pj4+PiBFbnZvecOpIDogbWFyZGkgMSBhdnJpbCAyMDE0IDIwOjQ0DQo+Pj4+ Pj4+IMOAIDogVGhvbWFzIE5hZGVhdQ0KPj4+Pj4+PiBDYyA6IERhcnJlbCBMZXdpcyAoZGFybGV3 aXMpOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOw0KPj4+Pj4+PnNmY0BpZXRmLm9yZw0KPj4+ Pj4+PiBPYmpldCA6IFJlOiBbc2ZjXSBSZW1vdmUgU2VjdGlvbiAzIGZyb20gdGhlIHByb2JsZW0g c3RhdGVtZW50ICh3YXMNCj4+Pj4+Pj5SRToNCj4+Pj4+SS1EDQo+Pj4+Pj4+IEFjdGlvbjogZHJh ZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMudHh0KQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBN eSBvcGluaW9uIGhhcyBub3QgY2hhbmdlZCwgdGhlIHNlY3Rpb24gc2VlbXMgdXNlZnVsIGFuZCBJ IHNlZSBubw0KPj4+Pj4+PnJlYXNvbg0KPj4+Pj5pdA0KPj4+Pj4+PiBzaG91bGQgYmUgcmVtb3Zl ZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLURhcnJlbA0KPj4+Pj4+PiBPbiBBcHIgMSwgMjAxNCwgYXQg NzoxNCBBTSwgVGhvbWFzIE5hZGVhdSA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+DQo+Pj4+Pndy b3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IAlUaGlzIGhhcyBjb21lIHVwIGJlZm9y ZSwgYW5kIHRoZXJlIHNlZW1lZCB0byBiZSBhIGxvdCBvZiBmb2xrcw0KPj4+d2hvDQo+Pj4+Pj4+ IHdhbnRlZCB0byBsZWF2ZSBzZWN0aW9uIDMgaW4gdGhlIGRvY3VtZW50LCBidXQgSSB3aWxsIGxl dCB0aGUgY2hhaXJzDQo+Pj4+Pm1ha2UNCj4+Pj4+Pj4gdGhlIGNvbnNlbnN1cyBjYWxsLg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMv Y3VycmVudC9tc2cwMDg5Ni5odG1sDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gCS0tVG9tDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIEFwciAxLCAyMDE0Ojc6NDIgQU0sIGF0IDc6NDIgQU0s IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4+Pj4+PiA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IERlYXIgYWxsLA0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSSByYWlzZWQgdGhpcyBwb2ludCB0byB0aGUgY28tYXV0aG9ycyBi dXQgSSBwcmVmZXIgdG8gcmFpc2UgaXQNCj4+Pj4+Pj4+PmFsc28NCj4+Pj4+Pj4+PmluDQo+Pj4+ Pj4+IHRoZSBtYWlsaW5nIGxpc3QuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHN1Z2dlc3QgdG8g cmVtb3ZlIFNlY3Rpb24gMyBmcm9tIHRoZSBkcmFmdA0KPj4+Pj4+Pg0KPj4+Pj4+Pmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAzI3Nl Y3Rpbw0KPj4+Pj4+Pm4tDQo+Pj4+PjMsDQo+Pj4+Pj4+IGJlY2F1c2UgaXQgZ29lcyBiZXlvbmQg dGhlIHByb2JsZW0gZGlzY3Vzc2lvbi4gVGhhdCBzZWN0aW9uIGlzIG1vcmUNCj4+Pj4+Pj5hDQo+ Pj4+Pj4+IGRpc2N1c3Npb24gdGhhdCBzaG91bGQgYmUgaG9zdGVkIGluIGEgZnJhbWV3b3JrIGRv Y3VtZW50Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gRnVydGhlcm1vcmUsIHNvbWUgb2YgdGhlIHBv aW50cyBtZW50aW9uZWQgaW4gdGhhdCBzZWN0aW9uIGFyZQ0KPj4+Pj4+PiBxdWVzdGlvbmFibGUg c3VjaCBhcyB0aGUgdXNlIG9mIG1ldGFkYXRhIGFuZCB0aGUgbmVlZCBvZiBjb250cm9sDQo+Pj4+ PnByb3RvY29scywNCj4+Pj4+Pj4gZXRjLiBMZXQncyBhdm9pZCBtaXhpbmcgb2JqZWN0aXZlcyBh bmQgbGltaXQgdGhlIHNjb3BlIG9mIHRoZSBQUyBJLUQNCj4+Pj4+Pj50bw0KPj4+Pj50aGUNCj4+ Pj4+Pj4gaWRlbnRpZmljYXRpb24gdG8gdGhlIHByb2JsZW1zIHRvIGJlIHNvbHZlZC4NCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IEFzaWRlIG5vdCwgdGhlIFdHIGNoYXJ0ZXIgaXMgY2xlYXIgYWJvdXQg dGhlIHNjb3BlIG9mIHRoZSBQUyBJLUQ6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAiDQo+Pj4+Pj4+ Pj4gMS4gUHJvYmxlbSBTdGF0ZW1lbnQ6IFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGEgc3Vt bWFyeSBvZiB0aGUNCj4+Pj4+Pj4+PiBwcm9ibGVtIHNwYWNlIHRvIGJlIGFkZHJlc3NlZCBieSB0 aGUgU0ZDIHdvcmtpbmcgZ3JvdXAgaW5jbHVkaW5nDQo+Pj4+Pj4+Pj4gZXhhbXBsZSBoaWdoLWxl dmVsIHVzZSBjYXNlcy4NCj4+Pj4+Pj4+PiAiDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBDaGVlcnMs DQo+Pj4+Pj4+Pj4gTWVkDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+Pj4+Pj4+Pj4+IERlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUgaW50ZXJuZXQtDQo+Pj4+Pj4+Pj4+IGRyYWZ0c0BpZXRmLm9yZw0K Pj4+Pj4+Pj4+PiBFbnZvecOpIDogbWFyZGkgMSBhdnJpbCAyMDE0IDEyOjM4DQo+Pj4+Pj4+Pj4+ IMOAIDogaS1kLWFubm91bmNlQGlldGYub3JnDQo+Pj4+Pj4+Pj4+IENjIDogc2ZjQGlldGYub3Jn DQo+Pj4+Pj4+Pj4+IE9iamV0IDogW3NmY10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJv YmxlbS1zdGF0ZW1lbnQtMDMudHh0DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQo+Pj4+ Pj4+Pj4+SW50ZXJuZXQtRHJhZnRzDQo+Pj4+Pj4+Pj4+IGRpcmVjdG9yaWVzLg0KPj4+Pj4+Pj4+ PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu aW5nDQo+Pj4+Pj4+Pj4+V29ya2luZw0KPj4+Pj4+PiBHcm91cA0KPj4+Pj4+Pj4+PiBvZiB0aGUg SUVURi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgIFRpdGxlICAgICAgICAgICA6IFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW5pbmcgUHJvYmxlbSBTdGF0ZW1lbnQNCj4+Pj4+Pj4+Pj4gICAgIEF1 dGhvcnMgICAgICAgICA6IFBhdWwgUXVpbm4NCj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgIFRob21hcyBOYWRlYXUNCj4+Pj4+Pj4+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAzLnR4dA0KPj4+Pj4+Pj4+PiAJUGFnZXMgICAgICAg ICAgIDogMTgNCj4+Pj4+Pj4+Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTQtMDQtMDENCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4+IFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGgNCj4+Pj4+Pj4+ Pj50aGUNCj4+Pj4+Pj4+Pj4gZGVwbG95bWVudCBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyAoc3VjaCBh cyBmaXJld2FsbHMsIGxvYWQNCj4+Pj4+Pj4+Pj5iYWxhbmNlcnMpDQo+Pj4+Pj4+Pj4+IGluIGxh cmdlLXNjYWxlIGVudmlyb25tZW50cy4gIFRoZSB0ZXJtIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcNCj4+Pj4+Pj4+Pj5pcw0KPj4+Pj4+Pj4+PiB1c2VkIHRvIGRlc2NyaWJlIHRoZSBkZWZpbml0 aW9uIGFuZCBpbnN0YW50aWF0aW9uIG9mIGFuIG9yZGVyZWQNCj4+Pj4+Pj4+Pj5zZXQNCj4+Pj4+ Pj4+Pj4gb2YgaW5zdGFuY2VzIG9mIHN1Y2ggc2VydmljZSBmdW5jdGlvbnMsIGFuZCB0aGUgc3Vi c2VxdWVudA0KPj4+Pj4+Pj4+PiJzdGVlcmluZyINCj4+Pj4+Pj4+Pj4gb2YgdHJhZmZpYyBmbG93 cyB0aHJvdWdoIHRob3NlIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBUaGUgc2V0IG9mIGVuYWJsZWQgc2VydmljZSBmdW5jdGlvbiBjaGFpbnMgcmVmbGVjdCBvcGVy YXRvcg0KPj4+Pj4+Pj4+PnNlcnZpY2UNCj4+Pj4+Pj4+Pj4gb2ZmZXJpbmdzIGFuZCBpcyBkZXNp Z25lZCBpbiBjb25qdW5jdGlvbiB3aXRoIGFwcGxpY2F0aW9uDQo+Pj4+Pj4+Pj4+ZGVsaXZlcnkN Cj4+Pj4+Pj4+Pj4gYW5kIHNlcnZpY2UgYW5kIG5ldHdvcmsgcG9saWN5Lg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC8NCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQo+Pj4+Pj4+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c2ZjLXByb2JsZW0tc3RhdGVtZW50LTAzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1w cm9ibGVtLXN0YXRlbWVudC0NCj4+Pj4+Pj4+Pj4wMw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+Pj4+Pj4+PiBzdWJtaXNzaW9uDQo+Pj4+Pj4+Pj4+IHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+ Pj4+Pj50b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+Pj4+Pj4+PiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBzZmNAaWV0 Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pg0KPj4N Cg0K From nobody Fri Apr 11 09:10:18 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 5AB1B1A071B for ; Fri, 11 Apr 2014 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 4PAHlnpGsBUD for ; Fri, 11 Apr 2014 09:10:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E03461A072E for ; Fri, 11 Apr 2014 09:10:12 -0700 (PDT) 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 BCZ77920; Fri, 11 Apr 2014 16:10:10 +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; Fri, 11 Apr 2014 17:09:00 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Apr 2014 17:10:09 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Fri, 11 Apr 2014 09:10:02 -0700 From: Linda Dunbar To: Kevin J Ma , "sfc@ietf.org" , "Ron Parker" Thread-Topic: Questions to draft-ma-sfc-decomposition-01.txt Thread-Index: AQHPVaB+JNLfe8PvyE+0xm89rW/5ZQ== Date: Fri, 11 Apr 2014 16:10:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF353C@dfweml701-chm.china.huawei.com> References: <20140210041400.31246.83214.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D541655C03@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D541655C03@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YKQZ8dLFqJOdkfdSHVo8Xs7iHXY Subject: [sfc] Questions to draft-ma-sfc-decomposition-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: Fri, 11 Apr 2014 16:10:16 -0000 Kevin and Ron,=20 Your draft described a very interesting use case of metadata exchange betwe= en (component) service functions.=20 For Figure (page 9) under Section 2.3 (Non-SFC Service Decomposition), is t= he intent for describing how it works without Service Function Chain? Where= as the Figure under 2.2 is to show how it works with Service Function chain= ?=20 Why it is necessary to have "Classifier" between "Service Request Routing" = and "Subscriber Entitlement Lookup" in non-SFC case? Whereas, in the 2.2, t= here is no "Classifier"?=20 In the second figure under Section 2.3, the only difference between the two= boxes under "M1" vs. "S2" is "HLS Manifest Rewrite" vs. "Segment decrypt/r= emux". Why can't branching happen after the "HLS Policy Enforcement"? Thanks, Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Sunday, February 09, 2014 10:33 PM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-= 00.txt Hi All, I've uploaded a new draft dealing with service decomposition. In some respects it also addresses some of the recent discussion about bidirectional flow association and re-classification, using an HLS video delivery optimization use case. Comments welcome. Jim/Thomas, =20 If there is space in the agenda, I would like to request a slot. The draft primarily relates to use cases. thanx. -- Kevin J. Ma -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, February 09, 2014 11:14 PM To: Kevin J Ma; Kevin J Ma Subject: New Version Notification for draft-ma-sfc-decomposition-00.txt A new version of I-D, draft-ma-sfc-decomposition-00.txt has been successfully submitted by Kevin J. Ma and posted to the IETF repository. Name: draft-ma-sfc-decomposition Revision: 00 Title: SFC Service Decomposition Document date: 2014-02-10 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-ma-sfc-decomposit= ion-00.txt Status: https://datatracker.ietf.org/doc/draft-ma-sfc-decomposition= / Htmlized: http://tools.ietf.org/html/draft-ma-sfc-decomposition-00 Abstract: This document discusses the role of composite (monolithic) service functions in service function chaining, and describes a method for supporting composite service function decomposition. = =20 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. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 11 10:45: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 67C081A072E for ; Fri, 11 Apr 2014 10:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 FOVvvP9D-Wb4 for ; Fri, 11 Apr 2014 10:45:29 -0700 (PDT) Received: from mc26.lon.server.colt.net (mc26.lon.server.colt.net [212.74.77.106]) by ietfa.amsl.com (Postfix) with ESMTP id A587B1A0706 for ; Fri, 11 Apr 2014 10:45:28 -0700 (PDT) Received: from mc26.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4CBCFC0081 for ; Fri, 11 Apr 2014 17:44:56 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc26.lon.server.colt.net (Postfix) with ESMTP id 32A09C0068 for ; Fri, 11 Apr 2014 17:44:56 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,843,1389740400"; d="scan'208";a="962870" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 11 Apr 2014 19:44:55 +0200 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([10.12.1.3]) with mapi id 14.01.0438.000; Fri, 11 Apr 2014 19:44:54 +0200 From: Nicolas BOUTHORS To: "sfc@ietf.org" Thread-Topic: Congruent metadata signaling considerations Thread-Index: AQHPVa2/ahGWZwmpSESoUJ2YHsgIzA== Date: Fri, 11 Apr 2014 17:44:54 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D43C513@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1017-20626.001 X-TM-AS-Result: No--18.994-5.0-31-10 X-imss-scan-details: No--18.994-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1017-20626.001 X-TMASE-Result: 10--18.994200-5.000000 X-TMASE-MatchedRID: HNWHGF9Y0Uv8BymGA9MWAsFWmsryu9ZfmebK96gg03aoqWMfbJIyPH3V cFZ/Q/et86lfaWv1uB4hOEHXxxatqbE/yjHHt6WeK1XEgm57RQPAuWcdTSiQDeRmz46Q29bDDT9 yMWZunWdJ8dkRTsyowMZZ/zoGHe6xkfLugziW86eQmLXB14cW2pZ6zKu0q4rt2e73tJcoE9jnc3 eF4PnDuTO8AZxbo4hb769lMZ2RXTTAz7VDjguSqOwSNio74PJoNNuh+5zmS69rMbakJN8OeQtRr zzqjnThanx0I9vCkpj9M0DAXEweJfnVY0DWsTq3VU3yVpaj3Qwhdi6zxllm1hV9YVbuTXD/dheN PERaTAD0ReYh6tgA39EpKGj7PhRJYNLPQiXPF7wZC8k/03bY5ZnaxzJFBx6vLO3j+XDwlkPUdtH M7EKWRyPjMs3c1moBMblbAAttHSNGPqvMHhkuCv9Ci025qU0x4b+uxQ/rA9bDV+mMbk1eU0H13s Td5nmQscHg2GWvIKA3k9vPJrLE1Ldi5+5RlO7dcYGYuKj6YmAL8TGleseLPOVWrwawFeMFRF1IZ CJolnMO7iSv8EEUqX8GdAV54d6Sti+2Rq0aYw3M1jffIgQXhip+ZAwEv4mSPi2WkVF4xvtRTmJ1 jjwch8SDi72BOmnvipLBulCN8G8AzT8btdR14wCwcUB5CbVq4+ZcrqvCDkHegYBpEHp4baPFjJE Fr+olpPKClyoUSzyNo+PRbWqfRJBlLa6MK1y4 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/807LRmjfbXxRX2PZmmTnZdoWBI0 Subject: [sfc] Congruent metadata signaling considerations 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, 11 Apr 2014 17:45:33 -0000 I am interested in exploring the notion of congruent out-of-band metadata s= ignaling =0A= as defined in section 3.3 of draft-rijsman-sfc-metadata-considerations. = =0A= =0A= A simple view is to allow SFs in a chain to send Metadata along the chain, = potentially thanks to the=0A= routing capabilities introduced by the SFC header. =0A= =0A= A simple flag in the SFC header could point out that the frame is a Metadat= a signaling frame (no =0A= subscriber traffic payload included), so it should be simple for a Service = Node SFF receiving a frame =0A= to trigger some special processing, for example to pass the information to = an application. =0A= =0A= Still as Joel pointed out in previous discussions, such a service incur som= e limitations. In particular:=0A= =0A= - Packet ordering is not insured: so a packet triggering some metadata crea= tion could arrive after =0A= the corresponding Congruent Metadata signaling message.=0A= - Metadata messages can be lost=0A= =0A= This said, there are some well known solutions to send reliably data or fra= mes over an unreliable =0A= network. I can see using SCTP are one option, to send Metadata hop to hop w= hile in a chain.=0A= =0A= This can probably done in different ways, and deserves to be studied and wr= itten down.=0A= =0A= I am interested to know if members thinks of other candidates on building a= reliable congruent=0A= metadata signaling service for our chains.=0A= =0A= SCTP seems interesting in that it provide a reliable service and has some s= upport for security. It might=0A= be however difficult to deal with packet ordering, unless we can call for s= ome support from the SFC header for (normal) subscriber traffic.=0A= =0A= Any thoughts?=0A= =0A= Nicolas=0A= =0A= =0A= ________________________________________=0A= From: Nicolas BOUTHORS=0A= Sent: Thursday, April 10, 2014 3:16 PM=0A= To: Joel M. Halpern; Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.n= et; Ron Parker=0A= Cc: sfc@ietf.org=0A= Subject: RE: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-c= onsiderations=0A= =0A= Hello=0A= =0A= I can see the benefit, as shown by Linda, to distinguish how to convey meta= data according to which function=0A= will benefit from its use.=0A= =0A= The metadata draft from Bruno shows many possibilities. At the same time, t= here are discussions on=0A= how intelligent/flexible a SFF should/could be. I think an Openflow based S= FF for example could=0A= provide added value, provided it finds in the SFC header enough information= .=0A= =0A= A fixed size header can carry a number of information allowing Service Swit= ching Functions to take local=0A= decision on how to handle incoming or outgoing traffic. I share with Linda = the feeling that an application Id=0A= field and a fine grain policy field, will enable innovation compared to a = header opaque or without any=0A= metadata.=0A= =0A= Congruent metadata messages are a good complement to send information from = one SF or another one,=0A= There are ways to allow SF to retrieve this information, just as there are = ways for SF to retreive out of band=0A= metadata. In both cases, the metadata messages are not constrained in size,= and some standard format=0A= exists already to carry similar information.=0A= =0A= =0A= Nicolas=0A= ________________________________________=0A= From: Joel M. Halpern [jmh@joelhalpern.com]=0A= Sent: Wednesday, April 09, 2014 2:17 PM=0A= To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron Parker=0A= Cc: sfc@ietf.org=0A= Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-c= onsiderations=0A= =0A= Maybe I am misreading your notes.=0A= =0A= The first part of your reply seems to say that there are existing=0A= techniques by which some service functions can pass data on to some=0A= other service functions. That is true. That does not mean that the=0A= range of needs is addressed. You even seem to acknowledge that.=0A= =0A= You then go on to say that we should only address the other problem=0A= (metadata between service functions and network nodes).=0A= =0A= Given that a large part of the problem of carrying metadata between=0A= service functions is not addressed currently, I do not see why we should=0A= neglect addressing that major problem.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 4/8/14, 9:12 PM, Linda Dunbar wrote:=0A= >=0A= > Joel,=0A= >=0A= > Today's proxy based service functions terminate TCP session and=0A= > restart the TCP session to the next service function or the=0A= > destination of the packet. Some of them attach data/cookies to the=0A= > packet.=0A= >=0A= > All those are strictly between service functions.=0A= >=0A= > I didn't say anything about "DPI service function passing to a=0A= > content manipulation service function the media type and offset to=0A= > the content".=0A= >=0A= > There have been proposals (not at IETF yet) for having a fixed header=0A= > field in data packets for a service function to insert some marker=0A= > (or identifier) for network nodes to steer the packet without looking=0A= > deeper into the packets, or vise versa. Those metadata between=0A= > "service function" and "network node" should be the one that requires=0A= > Metadata standardization.=0A= >=0A= > Yours,=0A= >=0A= > Linda=0A= >=0A= >=0A= > -----Original Message----- From: Joel M. Halpern=0A= > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM=0A= > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=0A= > Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to=0A= > draft-rijsman-sfc-metadata-considerations=0A= >=0A= > Your comment about metadata between service functions being handled=0A= > today seems to be based on some set of less than obvious assumptions.=0A= > I do not know of any applicable mechanism today whereby a DPI service=0A= > function can pass to a content manipulation service function the=0A= > media type and offset to the content. And that is only one example=0A= > of many.=0A= >=0A= > Even the few cases that are used today are typically done by=0A= > manipulation of the message content in a fragile fashion.=0A= >=0A= > Yours, Joel=0A= >=0A= > On 4/8/14, 6:27 PM, Linda Dunbar wrote:=0A= >> Bruno and Jerome,=0A= >>=0A= >> I like your analysis of various methods of carrying metadata and=0A= >> their associated challenges.=0A= >>=0A= >> But some "metadata" mentioned in your draft have been traditionally=0A= >> considered as part of policy, as the "20Mbps/30Mbps" used in your=0A= >> Figure 2.=0A= >>=0A= > ...=0A= >> For the "metadata" strictly between applications or between service=0A= >> functions, like the cookies attached to HTTP, today's Proxy Based=0A= >> service functions can already handle them well. It is debatable if=0A= >> any network header extension is needed for those metadata.=0A= >>=0A= >> For the "metadata" exchanged between Service functions and Network=0A= >> Nodes, there is definitely the need for standardized network layer=0A= >> header to carry those extra information.=0A= >>=0A= > ...=0A= >=0A= =0A= =0A= From nobody Sun Apr 13 13:11: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 1A23C1A0221 for ; Sun, 13 Apr 2014 13:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 Vodk1pTDfKl5 for ; Sun, 13 Apr 2014 13:11:38 -0700 (PDT) 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 5F0401A0242 for ; Sun, 13 Apr 2014 13:11:38 -0700 (PDT) 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.0174.001; Sun, 13 Apr 2014 13:11:36 -0700 From: Ron Parker To: Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: Congruent metadata signaling considerations Thread-Index: AQHPVa2/ahGWZwmpSESoUJ2YHsgIzJsP+z6w Date: Sun, 13 Apr 2014 20:11:34 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D43C513@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D43C513@LILAS.jungle.qosmos.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FrzA7bwpUeZCkrXLYnjFOPfo4XE Subject: Re: [sfc] Congruent metadata signaling considerations 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, 13 Apr 2014 20:11:41 -0000 Hi, Nicolas. I think that out-of-band metadata is a useful complement to inband metadata= , especially for long lived flows. In the same way that we haven't forced= a single transport encapsulation for the actual data packets, we don't nee= d to specify a transport for the out-of-band variant either. It could be = over TCP, SCTP, or even UDP or MAC if reliability is not required. It would be most beneficial if the same SFC header carried both inband and = out-of-band metadata. Have you evaluated http://datatracker.ietf.org/doc/= draft-zhang-sfc-sch/ for use as that common header? In the I-D, we propos= e a flexible TLV oriented approach to carriage of metadata. Since the pro= posed SCH header has, as one of its fields, the ethertype of the frame or p= acket that follows, we could reserve value 0 to mean "metadata only". We would also want to consider correlation. The easiest approach would be= to include the full MAC header or IP header of the flow that the metadata = belongs to. To accomplish this, we could define 2 metadata TLV types -- o= ne for a correlation MAC header and one for a correlation IP header. In t= he more complex case of wanting to correlate the out-of-band metadata to an= individual transaction (i.e., HTTP GET), then we could define a flow or tr= ansaction correlation TLV type that would be added to both the data stream = and the out-of-band data. Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Friday, April 11, 2014 1:45 PM To: sfc@ietf.org Subject: [sfc] Congruent metadata signaling considerations I am interested in exploring the notion of congruent out-of-band metadata s= ignaling as defined in section 3.3 of draft-rijsman-sfc-metadata-considerat= ions. =20 A simple view is to allow SFs in a chain to send Metadata along the chain, = potentially thanks to the routing capabilities introduced by the SFC header= . =20 A simple flag in the SFC header could point out that the frame is a Metadat= a signaling frame (no subscriber traffic payload included), so it should be= simple for a Service Node SFF receiving a frame=20 to trigger some special processing, for example to pass the information to = an application. =20 Still as Joel pointed out in previous discussions, such a service incur som= e limitations. In particular: - Packet ordering is not insured: so a packet triggering some metadata crea= tion could arrive after the corresponding Congruent Metadata signaling mess= age. - Metadata messages can be lost This said, there are some well known solutions to send reliably data or fra= mes over an unreliable network. I can see using SCTP are one option, to sen= d Metadata hop to hop while in a chain. This can probably done in different ways, and deserves to be studied and wr= itten down. I am interested to know if members thinks of other candidates on building a= reliable congruent metadata signaling service for our chains. SCTP seems interesting in that it provide a reliable service and has some s= upport for security. It might be however difficult to deal with packet orde= ring, unless we can call for some support from the SFC header for (normal) = subscriber traffic. Any thoughts? Nicolas ________________________________________ From: Nicolas BOUTHORS Sent: Thursday, April 10, 2014 3:16 PM To: Joel M. Halpern; Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.n= et; Ron Parker Cc: sfc@ietf.org Subject: RE: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-c= onsiderations Hello I can see the benefit, as shown by Linda, to distinguish how to convey meta= data according to which function will benefit from its use. The metadata draft from Bruno shows many possibilities. At the same time, t= here are discussions on how intelligent/flexible a SFF should/could be. I t= hink an Openflow based SFF for example could provide added value, provided = it finds in the SFC header enough information. A fixed size header can carry a number of information allowing Service Swit= ching Functions to take local decision on how to handle incoming or outgoin= g traffic. I share with Linda the feeling that an application Id field and = a fine grain policy field, will enable innovation compared to a header opa= que or without any metadata. Congruent metadata messages are a good complement to send information from = one SF or another one, There are ways to allow SF to retrieve this informat= ion, just as there are ways for SF to retreive out of band metadata. In bot= h cases, the metadata messages are not constrained in size, and some standa= rd format exists already to carry similar information. Nicolas ________________________________________ From: Joel M. Halpern [jmh@joelhalpern.com] Sent: Wednesday, April 09, 2014 2:17 PM To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron Parker Cc: sfc@ietf.org Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-c= onsiderations Maybe I am misreading your notes. The first part of your reply seems to say that there are existing technique= s by which some service functions can pass data on to some other service fu= nctions. That is true. That does not mean that the range of needs is addr= essed. You even seem to acknowledge that. You then go on to say that we should only address the other problem (metada= ta between service functions and network nodes). Given that a large part of the problem of carrying metadata between service= functions is not addressed currently, I do not see why we should neglect a= ddressing that major problem. Yours, Joel On 4/8/14, 9:12 PM, Linda Dunbar wrote: > > Joel, > > Today's proxy based service functions terminate TCP session and=20 > restart the TCP session to the next service function or the=20 > destination of the packet. Some of them attach data/cookies to the=20 > packet. > > All those are strictly between service functions. > > I didn't say anything about "DPI service function passing to a content=20 > manipulation service function the media type and offset to the=20 > content". > > There have been proposals (not at IETF yet) for having a fixed header=20 > field in data packets for a service function to insert some marker (or=20 > identifier) for network nodes to steer the packet without looking=20 > deeper into the packets, or vise versa. Those metadata between=20 > "service function" and "network node" should be the one that requires=20 > Metadata standardization. > > Yours, > > Linda > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=20 > Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to=20 > draft-rijsman-sfc-metadata-considerations > > Your comment about metadata between service functions being handled=20 > today seems to be based on some set of less than obvious assumptions. > I do not know of any applicable mechanism today whereby a DPI service=20 > function can pass to a content manipulation service function the media=20 > type and offset to the content. And that is only one example of many. > > Even the few cases that are used today are typically done by=20 > manipulation of the message content in a fragile fashion. > > Yours, Joel > > On 4/8/14, 6:27 PM, Linda Dunbar wrote: >> Bruno and Jerome, >> >> I like your analysis of various methods of carrying metadata and=20 >> their associated challenges. >> >> But some "metadata" mentioned in your draft have been traditionally=20 >> considered as part of policy, as the "20Mbps/30Mbps" used in your=20 >> Figure 2. >> > ... >> For the "metadata" strictly between applications or between service=20 >> functions, like the cookies attached to HTTP, today's Proxy Based=20 >> service functions can already handle them well. It is debatable if=20 >> any network header extension is needed for those metadata. >> >> For the "metadata" exchanged between Service functions and Network=20 >> Nodes, there is definitely the need for standardized network layer=20 >> header to carry those extra information. >> > ... > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Apr 13 13:25: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 9F3BF1A026B for ; Sun, 13 Apr 2014 13:25:52 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 swXwDrWDgb_x for ; Sun, 13 Apr 2014 13:25:51 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0842F1A0245 for ; Sun, 13 Apr 2014 13:25:51 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Sun, 13 Apr 2014 13:25:31 -0700 From: Ron Parker To: Linda Dunbar , Kevin J Ma , "sfc@ietf.org" Thread-Topic: Questions to draft-ma-sfc-decomposition-01.txt Thread-Index: AQHPVaCFc5fwQIHTkkaEVwW324jv6JsQAEZg Date: Sun, 13 Apr 2014 20:25:47 +0000 Message-ID: References: <20140210041400.31246.83214.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D541655C03@MAILR002.mail.lan> <4A95BA014132FF49AE685FAB4B9F17F645CF353C@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CF353C@dfweml701-chm.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/V_Cnp3U7507uW7gZx5E9k09rfu4 Subject: Re: [sfc] Questions to draft-ma-sfc-decomposition-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: Sun, 13 Apr 2014 20:25:52 -0000 Hi, Linda. Thanks for taking interest in our draft! Please see comments inline, below. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, April 11, 2014 12:10 PM To: Kevin J Ma; sfc@ietf.org; Ron Parker Subject: Questions to draft-ma-sfc-decomposition-01.txt Kevin and Ron,=20 Your draft described a very interesting use case of metadata exchange betwe= en (component) service functions.=20 For Figure (page 9) under Section 2.3 (Non-SFC Service Decomposition), is t= he intent for describing how it works without Service Function Chain? Where= as the Figure under 2.2 is to show how it works with Service Function chain= ?=20 Ron>> Yes, that is correct. Why it is necessary to have "Classifier" between "Service Request Routing" = and "Subscriber Entitlement Lookup" in non-SFC case? Whereas, in the 2.2, t= here is no "Classifier"?=20 Ron>> The SFC case shows the finer level of decomposition that is made poss= ible/feasible vs. the non SFC case. In the second figure under Section 2.3, the only difference between the two= boxes under "M1" vs. "S2" is "HLS Manifest Rewrite" vs. "Segment decrypt/r= emux". Why can't branching happen after the "HLS Policy Enforcement"? Ron>> I think that is a problem domain issue that Kevin could better answer= . However, this is meant to be an example of how SFC can enable finer gra= ined decomposition on a transaction (portion of flow) basis. Thanks, Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Sunday, February 09, 2014 10:33 PM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-= 00.txt Hi All, I've uploaded a new draft dealing with service decomposition. In some respects it also addresses some of the recent discussion about bidirectional flow association and re-classification, using an HLS video delivery optimization use case. Comments welcome. Jim/Thomas, =20 If there is space in the agenda, I would like to request a slot. The draft primarily relates to use cases. thanx. -- Kevin J. Ma -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, February 09, 2014 11:14 PM To: Kevin J Ma; Kevin J Ma Subject: New Version Notification for draft-ma-sfc-decomposition-00.txt A new version of I-D, draft-ma-sfc-decomposition-00.txt has been successfully submitted by Kevin J. Ma and posted to the IETF repository. Name: draft-ma-sfc-decomposition Revision: 00 Title: SFC Service Decomposition Document date: 2014-02-10 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-ma-sfc-decomposit= ion-00.txt Status: https://datatracker.ietf.org/doc/draft-ma-sfc-decomposition= / Htmlized: http://tools.ietf.org/html/draft-ma-sfc-decomposition-00 Abstract: This document discusses the role of composite (monolithic) service functions in service function chaining, and describes a method for supporting composite service function decomposition. = =20 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. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Apr 13 13:30: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 8B3011A0225 for ; Sun, 13 Apr 2014 13:30:05 -0700 (PDT) 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 0ki845gHnkFd for ; Sun, 13 Apr 2014 13:30:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CA1A0210 for ; Sun, 13 Apr 2014 13:30:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 52645240209; Sun, 13 Apr 2014 13:30:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-122.clppva.east.verizon.net [70.106.135.122]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 076272401FC; Sun, 13 Apr 2014 13:29:59 -0700 (PDT) Message-ID: <534AF3C7.8070803@joelhalpern.com> Date: Sun, 13 Apr 2014 16:29:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ron Parker , Nicolas BOUTHORS , "sfc@ietf.org" References: <76B41B8FACE1514795D30EC137FF391D43C513@LILAS.jungle.qosmos.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/V8tz4EaoForYFagNDQdSXz0AKoE Subject: Re: [sfc] Congruent metadata signaling considerations 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, 13 Apr 2014 20:30:05 -0000 I am a little concerned by the suggestion of SCTP or TCP for propagating out-of-band metadata. It implies that the application providing the metadata is aware of the chain, aware of which application needs the metadata, and has already setup connections to all the apps which follow it in the chain. It also seems to imply that even applications which are not handling metadata need to have such information and connectivity, since they need to propagate the metadata along the chain. This leads to having to create two fully aligned sets of information flows, the second one of which requires connection maintenance. Having information which is maintained by other systems, and which is fetched and cached by applications seems quite tractable. Trying to pass the information reliably along the chain, but separate from the actual data, seems quite difficult and complex. Yours, Joel On 4/13/14, 4:11 PM, Ron Parker wrote: > Hi, Nicolas. > > I think that out-of-band metadata is a useful complement to inband > metadata, especially for long lived flows. In the same way that we > haven't forced a single transport encapsulation for the actual data > packets, we don't need to specify a transport for the out-of-band > variant either. It could be over TCP, SCTP, or even UDP or MAC if > reliability is not required. > > It would be most beneficial if the same SFC header carried both > inband and out-of-band metadata. Have you evaluated > http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for use as that > common header? In the I-D, we propose a flexible TLV oriented > approach to carriage of metadata. Since the proposed SCH header > has, as one of its fields, the ethertype of the frame or packet that > follows, we could reserve value 0 to mean "metadata only". > > We would also want to consider correlation. The easiest approach > would be to include the full MAC header or IP header of the flow that > the metadata belongs to. To accomplish this, we could define 2 > metadata TLV types -- one for a correlation MAC header and one for a > correlation IP header. In the more complex case of wanting to > correlate the out-of-band metadata to an individual transaction > (i.e., HTTP GET), then we could define a flow or transaction > correlation TLV type that would be added to both the data stream and > the out-of-band data. > > Thanks. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Nicolas BOUTHORS Sent: Friday, April 11, 2014 1:45 PM To: > sfc@ietf.org Subject: [sfc] Congruent metadata signaling > considerations > > I am interested in exploring the notion of congruent out-of-band > metadata signaling as defined in section 3.3 of > draft-rijsman-sfc-metadata-considerations. > > A simple view is to allow SFs in a chain to send Metadata along the > chain, potentially thanks to the routing capabilities introduced by > the SFC header. > > A simple flag in the SFC header could point out that the frame is a > Metadata signaling frame (no subscriber traffic payload included), so > it should be simple for a Service Node SFF receiving a frame to > trigger some special processing, for example to pass the information > to an application. > > Still as Joel pointed out in previous discussions, such a service > incur some limitations. In particular: > > - Packet ordering is not insured: so a packet triggering some > metadata creation could arrive after the corresponding Congruent > Metadata signaling message. - Metadata messages can be lost > > This said, there are some well known solutions to send reliably data > or frames over an unreliable network. I can see using SCTP are one > option, to send Metadata hop to hop while in a chain. > > This can probably done in different ways, and deserves to be studied > and written down. > > I am interested to know if members thinks of other candidates on > building a reliable congruent metadata signaling service for our > chains. > > SCTP seems interesting in that it provide a reliable service and has > some support for security. It might be however difficult to deal with > packet ordering, unless we can call for some support from the SFC > header for (normal) subscriber traffic. > > Any thoughts? > > Nicolas > > > ________________________________________ From: Nicolas BOUTHORS Sent: > Thursday, April 10, 2014 3:16 PM To: Joel M. Halpern; Linda Dunbar; > brijsman@juniper.net; jmoisand@juniper.net; Ron Parker Cc: > sfc@ietf.org Subject: RE: [sfc] Comments and suggestions to > draft-rijsman-sfc-metadata-considerations > > Hello > > I can see the benefit, as shown by Linda, to distinguish how to > convey metadata according to which function will benefit from its > use. > > The metadata draft from Bruno shows many possibilities. At the same > time, there are discussions on how intelligent/flexible a SFF > should/could be. I think an Openflow based SFF for example could > provide added value, provided it finds in the SFC header enough > information. > > A fixed size header can carry a number of information allowing > Service Switching Functions to take local decision on how to handle > incoming or outgoing traffic. I share with Linda the feeling that an > application Id field and a fine grain policy field, will enable > innovation compared to a header opaque or without any metadata. > > Congruent metadata messages are a good complement to send information > from one SF or another one, There are ways to allow SF to retrieve > this information, just as there are ways for SF to retreive out of > band metadata. In both cases, the metadata messages are not > constrained in size, and some standard format exists already to carry > similar information. > > > Nicolas ________________________________________ From: Joel M. > Halpern [jmh@joelhalpern.com] Sent: Wednesday, April 09, 2014 2:17 > PM To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron > Parker Cc: sfc@ietf.org Subject: Re: [sfc] Comments and suggestions > to draft-rijsman-sfc-metadata-considerations > > Maybe I am misreading your notes. > > The first part of your reply seems to say that there are existing > techniques by which some service functions can pass data on to some > other service functions. That is true. That does not mean that the > range of needs is addressed. You even seem to acknowledge that. > > You then go on to say that we should only address the other problem > (metadata between service functions and network nodes). > > Given that a large part of the problem of carrying metadata between > service functions is not addressed currently, I do not see why we > should neglect addressing that major problem. > > Yours, Joel > > On 4/8/14, 9:12 PM, Linda Dunbar wrote: >> >> Joel, >> >> Today's proxy based service functions terminate TCP session and >> restart the TCP session to the next service function or the >> destination of the packet. Some of them attach data/cookies to the >> packet. >> >> All those are strictly between service functions. >> >> I didn't say anything about "DPI service function passing to a >> content manipulation service function the media type and offset to >> the content". >> >> There have been proposals (not at IETF yet) for having a fixed >> header field in data packets for a service function to insert some >> marker (or identifier) for network nodes to steer the packet >> without looking deeper into the packets, or vise versa. Those >> metadata between "service function" and "network node" should be >> the one that requires Metadata standardization. >> >> Yours, >> >> Linda >> >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM >> To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron >> Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to >> draft-rijsman-sfc-metadata-considerations >> >> Your comment about metadata between service functions being >> handled today seems to be based on some set of less than obvious >> assumptions. I do not know of any applicable mechanism today >> whereby a DPI service function can pass to a content manipulation >> service function the media type and offset to the content. And >> that is only one example of many. >> >> Even the few cases that are used today are typically done by >> manipulation of the message content in a fragile fashion. >> >> Yours, Joel >> >> On 4/8/14, 6:27 PM, Linda Dunbar wrote: >>> Bruno and Jerome, >>> >>> I like your analysis of various methods of carrying metadata and >>> their associated challenges. >>> >>> But some "metadata" mentioned in your draft have been >>> traditionally considered as part of policy, as the >>> "20Mbps/30Mbps" used in your Figure 2. >>> >> ... >>> For the "metadata" strictly between applications or between >>> service functions, like the cookies attached to HTTP, today's >>> Proxy Based service functions can already handle them well. It is >>> debatable if any network header extension is needed for those >>> metadata. >>> >>> For the "metadata" exchanged between Service functions and >>> Network Nodes, there is definitely the need for standardized >>> network layer header to carry those extra information. >>> >> ... >> > > > > _______________________________________________ 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 nobody Sun Apr 13 13:36:18 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 EEC871A0210 for ; Sun, 13 Apr 2014 13:36:15 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 M4nzVW1A0FSX for ; Sun, 13 Apr 2014 13:36:13 -0700 (PDT) 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 8CBB61A0225 for ; Sun, 13 Apr 2014 13:36:13 -0700 (PDT) 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.0174.001; Sun, 13 Apr 2014 13:36:11 -0700 From: Ron Parker To: "Joel M. Halpern" , Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: [sfc] Congruent metadata signaling considerations Thread-Index: AQHPVa2/ahGWZwmpSESoUJ2YHsgIzJsP+z6wgAB9BoD//4uhgA== Date: Sun, 13 Apr 2014 20:36:10 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D43C513@LILAS.jungle.qosmos.com> <534AF3C7.8070803@joelhalpern.com> In-Reply-To: <534AF3C7.8070803@joelhalpern.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vdDM54K_stjy82MPX8JaccSz3Rg Subject: Re: [sfc] Congruent metadata signaling considerations 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, 13 Apr 2014 20:36:16 -0000 Joel, I don't think out-of-band will be the predominant mode due to the complexit= ies that have been discussed on this thread and those that you raise here. = However, for certain special case scenarios, I could see benefit. Regar= ding the need for the application to understand the other located service f= unction instances in the chain, I think this can be handled in a control pl= ane.=20 Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Sunday, April 13, 2014 4:30 PM To: Ron Parker; Nicolas BOUTHORS; sfc@ietf.org Subject: Re: [sfc] Congruent metadata signaling considerations I am a little concerned by the suggestion of SCTP or TCP for propagating ou= t-of-band metadata. It implies that the application providing the metadata is aware of the chai= n, aware of which application needs the metadata, and has already setup con= nections to all the apps which follow it in the chain. It also seems to im= ply that even applications which are not handling metadata need to have suc= h information and connectivity, since they need to propagate the metadata a= long the chain. This leads to having to create two fully aligned sets of information flows,= the second one of which requires connection maintenance. Having information which is maintained by other systems, and which is fetch= ed and cached by applications seems quite tractable. Trying to pass the in= formation reliably along the chain, but separate from the actual data, seem= s quite difficult and complex. Yours, Joel On 4/13/14, 4:11 PM, Ron Parker wrote: > Hi, Nicolas. > > I think that out-of-band metadata is a useful complement to inband > metadata, especially for long lived flows. In the same way that we > haven't forced a single transport encapsulation for the actual data=20 > packets, we don't need to specify a transport for the out-of-band > variant either. It could be over TCP, SCTP, or even UDP or MAC if > reliability is not required. > > It would be most beneficial if the same SFC header carried both > inband and out-of-band metadata. Have you evaluated > http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for use as that > common header? In the I-D, we propose a flexible TLV oriented > approach to carriage of metadata. Since the proposed SCH header > has, as one of its fields, the ethertype of the frame or packet that=20 > follows, we could reserve value 0 to mean "metadata only". > > We would also want to consider correlation. The easiest approach > would be to include the full MAC header or IP header of the flow that > the metadata belongs to. To accomplish this, we could define 2 > metadata TLV types -- one for a correlation MAC header and one for a > correlation IP header. In the more complex case of wanting to > correlate the out-of-band metadata to an individual transaction (i.e.,=20 > HTTP GET), then we could define a flow or transaction correlation TLV=20 > type that would be added to both the data stream and the out-of-band=20 > data. > > Thanks. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of Nicolas BOUTHORS Sent: Friday, April 11, 2014 1:45 PM To: > sfc@ietf.org Subject: [sfc] Congruent metadata signaling=20 > considerations > > I am interested in exploring the notion of congruent out-of-band=20 > metadata signaling as defined in section 3.3 of=20 > draft-rijsman-sfc-metadata-considerations. > > A simple view is to allow SFs in a chain to send Metadata along the=20 > chain, potentially thanks to the routing capabilities introduced by=20 > the SFC header. > > A simple flag in the SFC header could point out that the frame is a=20 > Metadata signaling frame (no subscriber traffic payload included), so=20 > it should be simple for a Service Node SFF receiving a frame to=20 > trigger some special processing, for example to pass the information=20 > to an application. > > Still as Joel pointed out in previous discussions, such a service=20 > incur some limitations. In particular: > > - Packet ordering is not insured: so a packet triggering some metadata=20 > creation could arrive after the corresponding Congruent Metadata=20 > signaling message. - Metadata messages can be lost > > This said, there are some well known solutions to send reliably data=20 > or frames over an unreliable network. I can see using SCTP are one=20 > option, to send Metadata hop to hop while in a chain. > > This can probably done in different ways, and deserves to be studied=20 > and written down. > > I am interested to know if members thinks of other candidates on=20 > building a reliable congruent metadata signaling service for our=20 > chains. > > SCTP seems interesting in that it provide a reliable service and has=20 > some support for security. It might be however difficult to deal with=20 > packet ordering, unless we can call for some support from the SFC=20 > header for (normal) subscriber traffic. > > Any thoughts? > > Nicolas > > > ________________________________________ From: Nicolas BOUTHORS Sent: > Thursday, April 10, 2014 3:16 PM To: Joel M. Halpern; Linda Dunbar;=20 > brijsman@juniper.net; jmoisand@juniper.net; Ron Parker Cc: > sfc@ietf.org Subject: RE: [sfc] Comments and suggestions to=20 > draft-rijsman-sfc-metadata-considerations > > Hello > > I can see the benefit, as shown by Linda, to distinguish how to convey=20 > metadata according to which function will benefit from its use. > > The metadata draft from Bruno shows many possibilities. At the same=20 > time, there are discussions on how intelligent/flexible a SFF=20 > should/could be. I think an Openflow based SFF for example could=20 > provide added value, provided it finds in the SFC header enough=20 > information. > > A fixed size header can carry a number of information allowing Service=20 > Switching Functions to take local decision on how to handle incoming=20 > or outgoing traffic. I share with Linda the feeling that an=20 > application Id field and a fine grain policy field, will enable=20 > innovation compared to a header opaque or without any metadata. > > Congruent metadata messages are a good complement to send information=20 > from one SF or another one, There are ways to allow SF to retrieve=20 > this information, just as there are ways for SF to retreive out of=20 > band metadata. In both cases, the metadata messages are not=20 > constrained in size, and some standard format exists already to carry=20 > similar information. > > > Nicolas ________________________________________ From: Joel M. > Halpern [jmh@joelhalpern.com] Sent: Wednesday, April 09, 2014 2:17 PM=20 > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=20 > Parker Cc: sfc@ietf.org Subject: Re: [sfc] Comments and suggestions to=20 > draft-rijsman-sfc-metadata-considerations > > Maybe I am misreading your notes. > > The first part of your reply seems to say that there are existing=20 > techniques by which some service functions can pass data on to some=20 > other service functions. That is true. That does not mean that the=20 > range of needs is addressed. You even seem to acknowledge that. > > You then go on to say that we should only address the other problem=20 > (metadata between service functions and network nodes). > > Given that a large part of the problem of carrying metadata between=20 > service functions is not addressed currently, I do not see why we=20 > should neglect addressing that major problem. > > Yours, Joel > > On 4/8/14, 9:12 PM, Linda Dunbar wrote: >> >> Joel, >> >> Today's proxy based service functions terminate TCP session and=20 >> restart the TCP session to the next service function or the=20 >> destination of the packet. Some of them attach data/cookies to the=20 >> packet. >> >> All those are strictly between service functions. >> >> I didn't say anything about "DPI service function passing to a=20 >> content manipulation service function the media type and offset to=20 >> the content". >> >> There have been proposals (not at IETF yet) for having a fixed header=20 >> field in data packets for a service function to insert some marker=20 >> (or identifier) for network nodes to steer the packet without looking=20 >> deeper into the packets, or vise versa. Those metadata between=20 >> "service function" and "network node" should be the one that requires=20 >> Metadata standardization. >> >> Yours, >> >> Linda >> >> >> -----Original Message----- From: Joel M. Halpern=20 >> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM >> To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=20 >> Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to=20 >> draft-rijsman-sfc-metadata-considerations >> >> Your comment about metadata between service functions being handled=20 >> today seems to be based on some set of less than obvious assumptions.=20 >> I do not know of any applicable mechanism today whereby a DPI service=20 >> function can pass to a content manipulation service function the=20 >> media type and offset to the content. And that is only one example=20 >> of many. >> >> Even the few cases that are used today are typically done by=20 >> manipulation of the message content in a fragile fashion. >> >> Yours, Joel >> >> On 4/8/14, 6:27 PM, Linda Dunbar wrote: >>> Bruno and Jerome, >>> >>> I like your analysis of various methods of carrying metadata and=20 >>> their associated challenges. >>> >>> But some "metadata" mentioned in your draft have been traditionally=20 >>> considered as part of policy, as the "20Mbps/30Mbps" used in your=20 >>> Figure 2. >>> >> ... >>> For the "metadata" strictly between applications or between service=20 >>> functions, like the cookies attached to HTTP, today's Proxy Based=20 >>> service functions can already handle them well. It is debatable if=20 >>> any network header extension is needed for those metadata. >>> >>> For the "metadata" exchanged between Service functions and Network=20 >>> Nodes, there is definitely the need for standardized network layer=20 >>> header to carry those extra information. >>> >> ... >> > > > > _______________________________________________ sfc mailing list=20 > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ sfc mailing list=20 > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Apr 13 14:01: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 C4BD11A0235 for ; Sun, 13 Apr 2014 14:01:41 -0700 (PDT) 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 MvboEqbD_cke for ; Sun, 13 Apr 2014 14:01:38 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB6E1A0229 for ; Sun, 13 Apr 2014 14:01:37 -0700 (PDT) X-AuditID: c6180641-f79a26d000001830-18-534aaa4b4456 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 47.10.06192.B4AAA435; Sun, 13 Apr 2014 17:16:27 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Sun, 13 Apr 2014 17:01:26 -0400 From: Kevin Ma J To: Ron Parker , Linda Dunbar , Kevin J Ma , "sfc@ietf.org" Thread-Topic: Questions to draft-ma-sfc-decomposition-01.txt Thread-Index: AQHPVaB+JNLfe8PvyE+0xm89rW/5ZZsQROiA//+9wgA= Date: Sun, 13 Apr 2014 21:01:26 +0000 Message-ID: References: <20140210041400.31246.83214.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D541655C03@MAILR002.mail.lan> <4A95BA014132FF49AE685FAB4B9F17F645CF353C@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPoK73Kq9gg0+rFSzeTL3NbnG3ZSKT xYWnU5ktnjzYyu7A4vHiyjNmj4fbZjN6tBx5y+qxZMlPpgCWKC6blNSczLLUIn27BK6MQ0c3 Mhd81az4+qibuYHxomIXIyeHhICJxMO5JxkhbDGJC/fWs3UxcnEICRxllFj59SAjhLOcUeLj 5b0sIFVsAloSj7/+ZQJJiAgsZpRY3/SADSQhLGAt8WDLe7BRIgI2Eou/XGSDsK0kji6YC9bM IqAqsWblUWYQm1fAW+LW7FlQG+YzSbRNuArWwCkQLbHt+htWEJsR6Kbvp9YwgdjMAuISt57M Z4K4VUBiyZ7zzBC2qMTLx/9YIWwliTmvrzFD1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSd hWTsLCQts5C0zELSsoCRZRUjR2lxalluupHhJkZg7ByTYHPcwbjgk+UhRgEORiUe3mWTcwOE WBPLiitzDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx71b7ygdPXCMe 8Ajlu89R6Sz+9I11v7/xb+Ge951FWStVg4q2tpxM37o1wMLjuc1ByT7edfnl1oWlKfWzvrE4 +yfvemZ/4fpmyyX+ghN7TrrvDA7vXPBbdP37FM1NewvfG+94U8c4d3Ic78FHiXUTS1LbNMJ7 5X0YPE8Upu2U3/+T49IFaxElluKMREMt5qLiRAArfN/DfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/P7VHTyY5yNNQ_XTlXYFvrE1PClY Subject: Re: [sfc] Questions to draft-ma-sfc-decomposition-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: Sun, 13 Apr 2014 21:01:42 -0000 Hi Linda, Thank you for the comments. responses inline: thanx. -- Kevin J. Ma -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Sunday, April 13, 2014 4:26 PM To: Linda Dunbar; Kevin J Ma; sfc@ietf.org Subject: RE: Questions to draft-ma-sfc-decomposition-01.txt Hi, Linda. Thanks for taking interest in our draft! Please see comments inline, below. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Friday, April 11, 2014 12:10 PM To: Kevin J Ma; sfc@ietf.org; Ron Parker Subject: Questions to draft-ma-sfc-decomposition-01.txt Kevin and Ron,=20 Your draft described a very interesting use case of metadata exchange betwe= en (component) service functions.=20 For Figure (page 9) under Section 2.3 (Non-SFC Service Decomposition), is t= he intent for describing how it works without Service Function Chain? Where= as the Figure under 2.2 is to show how it works with Service Function chain= ?=20 Ron>> Yes, that is correct. [KJM] In 2.2, the figure shows a composite service function is viewed by th= e network as a single monolithic service function. The use or non-use of S= FC in this case probably doesn't matter; it could be either. This figure i= s really to setup the scenario for decomposing the composite service functi= on into component service functions. Why it is necessary to have "Classifier" between "Service Request Routing" = and "Subscriber Entitlement Lookup" in non-SFC case? Whereas, in the 2.2, t= here is no "Classifier"?=20 Ron>> The SFC case shows the finer level of decomposition that is made poss= ible/feasible vs. the non SFC case. [KJM] In 2.2, the composite service function is viewed by the network as a = single monolithic service function. In 2.3, the decomposition into three s= eparate ingress service function allows independent scaling and redundancy = for more granular service function definitions. wrt the classifier after "= Component Service 2", as mentioned in the text, TCP termination may be empl= oyed for header/URL rewrite, but also "Component Service 2" needs a way to = convey whether or not "Component Service 3" (i.e., whether or not back-end = TLS) should be used for a given flow, which in a non-SFC case would likely = be via a specific outbound VLAN or VIP, to be recognized by the subsequent = classifier. In the second figure under Section 2.3, the only difference between the two= boxes under "M1" vs. "S2" is "HLS Manifest Rewrite" vs. "Segment decrypt/r= emux". Why can't branching happen after the "HLS Policy Enforcement"? Ron>> I think that is a problem domain issue that Kevin could better answer= . However, this is meant to be an example of how SFC can enable finer gra= ined decomposition on a transaction (portion of flow) basis. [KJM] I probably could've made this more clear, but the types of policy enf= orcement performed on segments vs on manifests is different depending on wh= at specific features are being deployed. Perhaps the figure could be updated to reflec= t a distinction between "Manifest-based HLS policy enforcement" for M1 and = "Segment-based HLS policy enforcement" for S2? Thanks, Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Sunday, February 09, 2014 10:33 PM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-= 00.txt Hi All, I've uploaded a new draft dealing with service decomposition. In some respects it also addresses some of the recent discussion about bidirectional flow association and re-classification, using an HLS video delivery optimization use case. Comments welcome. Jim/Thomas, =20 If there is space in the agenda, I would like to request a slot. The draft primarily relates to use cases. thanx. -- Kevin J. Ma -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, February 09, 2014 11:14 PM To: Kevin J Ma; Kevin J Ma Subject: New Version Notification for draft-ma-sfc-decomposition-00.txt A new version of I-D, draft-ma-sfc-decomposition-00.txt has been successfully submitted by Kevin J. Ma and posted to the IETF repository. Name: draft-ma-sfc-decomposition Revision: 00 Title: SFC Service Decomposition Document date: 2014-02-10 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-ma-sfc-decomposit= ion-00.txt Status: https://datatracker.ietf.org/doc/draft-ma-sfc-decomposition= / Htmlized: http://tools.ietf.org/html/draft-ma-sfc-decomposition-00 Abstract: This document discusses the role of composite (monolithic) service functions in service function chaining, and describes a method for supporting composite service function decomposition. = =20 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. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 16 09:15: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 0DCFF1A023D for ; Wed, 16 Apr 2014 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 9rjw6vWCa35K for ; Wed, 16 Apr 2014 09:15:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5F1A021B for ; Wed, 16 Apr 2014 09:15:20 -0700 (PDT) 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 BFS21897; Wed, 16 Apr 2014 16:15:16 +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; Wed, 16 Apr 2014 17:13:52 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 17:15:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Wed, 16 Apr 2014 09:15:04 -0700 From: Linda Dunbar To: "Joel M. Halpern" , Ron Parker , Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: [sfc] Congruent metadata signaling considerations Thread-Index: AQHPVa2/ahGWZwmpSESoUJ2YHsgIzJsP+z6wgAB9BoCAA/hTYA== Date: Wed, 16 Apr 2014 16:15:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF6469@dfweml701-chm.china.huawei.com> References: <76B41B8FACE1514795D30EC137FF391D43C513@LILAS.jungle.qosmos.com> <534AF3C7.8070803@joelhalpern.com> In-Reply-To: <534AF3C7.8070803@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ImbzA9SZmEhD3V_qG5w0pFy3P2w Subject: Re: [sfc] Congruent metadata signaling considerations 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, 16 Apr 2014 16:15:26 -0000 There are two aspects of "congruency":=20 - Out-of-band metadata traverse same path as actual user data flows. - forward and reverse paths traversing same service functions.=20 To enforce the Out-of-band Metadata traversing the same path as actual user= data flows, it is important that they traverse the same SSF nodes in the s= ame order, but don't really matter which underlay nodes being traversed thr= ough, is it correct? To enforce the Metadata and user flow traversing the same SFF nodes in the = same order, can't we use the Tunneling methods (VxLAN, IP in IP, or others)= to achieve the goal? But how to enforce the forward & reverse paths traversing the same service = functions?=20 =20 Linda =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Sunday, April 13, 2014 3:30 PM To: Ron Parker; Nicolas BOUTHORS; sfc@ietf.org Subject: Re: [sfc] Congruent metadata signaling considerations I am a little concerned by the suggestion of SCTP or TCP for propagating ou= t-of-band metadata. It implies that the application providing the metadata is aware of the chai= n, aware of which application needs the metadata, and has already setup con= nections to all the apps which follow it in the chain. It also seems to im= ply that even applications which are not handling metadata need to have suc= h information and connectivity, since they need to propagate the metadata a= long the chain. This leads to having to create two fully aligned sets of information flows,= the second one of which requires connection maintenance. Having information which is maintained by other systems, and which is fetch= ed and cached by applications seems quite tractable. Trying to pass the in= formation reliably along the chain, but separate from the actual data, seem= s quite difficult and complex. Yours, Joel On 4/13/14, 4:11 PM, Ron Parker wrote: > Hi, Nicolas. > > I think that out-of-band metadata is a useful complement to inband > metadata, especially for long lived flows. In the same way that we > haven't forced a single transport encapsulation for the actual data=20 > packets, we don't need to specify a transport for the out-of-band > variant either. It could be over TCP, SCTP, or even UDP or MAC if > reliability is not required. > > It would be most beneficial if the same SFC header carried both > inband and out-of-band metadata. Have you evaluated > http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for use as that > common header? In the I-D, we propose a flexible TLV oriented > approach to carriage of metadata. Since the proposed SCH header > has, as one of its fields, the ethertype of the frame or packet that=20 > follows, we could reserve value 0 to mean "metadata only". > > We would also want to consider correlation. The easiest approach > would be to include the full MAC header or IP header of the flow that > the metadata belongs to. To accomplish this, we could define 2 > metadata TLV types -- one for a correlation MAC header and one for a > correlation IP header. In the more complex case of wanting to > correlate the out-of-band metadata to an individual transaction (i.e.,=20 > HTTP GET), then we could define a flow or transaction correlation TLV=20 > type that would be added to both the data stream and the out-of-band=20 > data. > > Thanks. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of Nicolas BOUTHORS Sent: Friday, April 11, 2014 1:45 PM To: > sfc@ietf.org Subject: [sfc] Congruent metadata signaling=20 > considerations > > I am interested in exploring the notion of congruent out-of-band=20 > metadata signaling as defined in section 3.3 of=20 > draft-rijsman-sfc-metadata-considerations. > > A simple view is to allow SFs in a chain to send Metadata along the=20 > chain, potentially thanks to the routing capabilities introduced by=20 > the SFC header. > > A simple flag in the SFC header could point out that the frame is a=20 > Metadata signaling frame (no subscriber traffic payload included), so=20 > it should be simple for a Service Node SFF receiving a frame to=20 > trigger some special processing, for example to pass the information=20 > to an application. > > Still as Joel pointed out in previous discussions, such a service=20 > incur some limitations. In particular: > > - Packet ordering is not insured: so a packet triggering some metadata=20 > creation could arrive after the corresponding Congruent Metadata=20 > signaling message. - Metadata messages can be lost > > This said, there are some well known solutions to send reliably data=20 > or frames over an unreliable network. I can see using SCTP are one=20 > option, to send Metadata hop to hop while in a chain. > > This can probably done in different ways, and deserves to be studied=20 > and written down. > > I am interested to know if members thinks of other candidates on=20 > building a reliable congruent metadata signaling service for our=20 > chains. > > SCTP seems interesting in that it provide a reliable service and has=20 > some support for security. It might be however difficult to deal with=20 > packet ordering, unless we can call for some support from the SFC=20 > header for (normal) subscriber traffic. > > Any thoughts? > > Nicolas > > > ________________________________________ From: Nicolas BOUTHORS Sent: > Thursday, April 10, 2014 3:16 PM To: Joel M. Halpern; Linda Dunbar;=20 > brijsman@juniper.net; jmoisand@juniper.net; Ron Parker Cc: > sfc@ietf.org Subject: RE: [sfc] Comments and suggestions to=20 > draft-rijsman-sfc-metadata-considerations > > Hello > > I can see the benefit, as shown by Linda, to distinguish how to convey=20 > metadata according to which function will benefit from its use. > > The metadata draft from Bruno shows many possibilities. At the same=20 > time, there are discussions on how intelligent/flexible a SFF=20 > should/could be. I think an Openflow based SFF for example could=20 > provide added value, provided it finds in the SFC header enough=20 > information. > > A fixed size header can carry a number of information allowing Service=20 > Switching Functions to take local decision on how to handle incoming=20 > or outgoing traffic. I share with Linda the feeling that an=20 > application Id field and a fine grain policy field, will enable=20 > innovation compared to a header opaque or without any metadata. > > Congruent metadata messages are a good complement to send information=20 > from one SF or another one, There are ways to allow SF to retrieve=20 > this information, just as there are ways for SF to retreive out of=20 > band metadata. In both cases, the metadata messages are not=20 > constrained in size, and some standard format exists already to carry=20 > similar information. > > > Nicolas ________________________________________ From: Joel M. > Halpern [jmh@joelhalpern.com] Sent: Wednesday, April 09, 2014 2:17 PM=20 > To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=20 > Parker Cc: sfc@ietf.org Subject: Re: [sfc] Comments and suggestions to=20 > draft-rijsman-sfc-metadata-considerations > > Maybe I am misreading your notes. > > The first part of your reply seems to say that there are existing=20 > techniques by which some service functions can pass data on to some=20 > other service functions. That is true. That does not mean that the=20 > range of needs is addressed. You even seem to acknowledge that. > > You then go on to say that we should only address the other problem=20 > (metadata between service functions and network nodes). > > Given that a large part of the problem of carrying metadata between=20 > service functions is not addressed currently, I do not see why we=20 > should neglect addressing that major problem. > > Yours, Joel > > On 4/8/14, 9:12 PM, Linda Dunbar wrote: >> >> Joel, >> >> Today's proxy based service functions terminate TCP session and=20 >> restart the TCP session to the next service function or the=20 >> destination of the packet. Some of them attach data/cookies to the=20 >> packet. >> >> All those are strictly between service functions. >> >> I didn't say anything about "DPI service function passing to a=20 >> content manipulation service function the media type and offset to=20 >> the content". >> >> There have been proposals (not at IETF yet) for having a fixed header=20 >> field in data packets for a service function to insert some marker=20 >> (or identifier) for network nodes to steer the packet without looking=20 >> deeper into the packets, or vise versa. Those metadata between=20 >> "service function" and "network node" should be the one that requires=20 >> Metadata standardization. >> >> Yours, >> >> Linda >> >> >> -----Original Message----- From: Joel M. Halpern=20 >> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 08, 2014 5:37 PM >> To: Linda Dunbar; brijsman@juniper.net; jmoisand@juniper.net; Ron=20 >> Parker Cc: sfc@ietf.org Subject: Re: Comments and suggestions to=20 >> draft-rijsman-sfc-metadata-considerations >> >> Your comment about metadata between service functions being handled=20 >> today seems to be based on some set of less than obvious assumptions.=20 >> I do not know of any applicable mechanism today whereby a DPI service=20 >> function can pass to a content manipulation service function the=20 >> media type and offset to the content. And that is only one example=20 >> of many. >> >> Even the few cases that are used today are typically done by=20 >> manipulation of the message content in a fragile fashion. >> >> Yours, Joel >> >> On 4/8/14, 6:27 PM, Linda Dunbar wrote: >>> Bruno and Jerome, >>> >>> I like your analysis of various methods of carrying metadata and=20 >>> their associated challenges. >>> >>> But some "metadata" mentioned in your draft have been traditionally=20 >>> considered as part of policy, as the "20Mbps/30Mbps" used in your=20 >>> Figure 2. >>> >> ... >>> For the "metadata" strictly between applications or between service=20 >>> functions, like the cookies attached to HTTP, today's Proxy Based=20 >>> service functions can already handle them well. It is debatable if=20 >>> any network header extension is needed for those metadata. >>> >>> For the "metadata" exchanged between Service functions and Network=20 >>> Nodes, there is definitely the need for standardized network layer=20 >>> header to carry those extra information. >>> >> ... >> > > > > _______________________________________________ sfc mailing list=20 > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ sfc mailing list=20 > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 16 11:37: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 18A031A01D7 for ; Wed, 16 Apr 2014 11:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vUO30ZBVhTIs for ; Wed, 16 Apr 2014 11:37:46 -0700 (PDT) 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 B149E1A01C8 for ; Wed, 16 Apr 2014 11:37:46 -0700 (PDT) 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.0174.001; Wed, 16 Apr 2014 11:37:43 -0700 From: Ron Parker To: "sfc@ietf.org" Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-00 Thread-Index: Ac9ZoN/oYzcTbeM+TgGZjuhgeN0QeQ== Date: Wed, 16 Apr 2014 18:37:42 +0000 Message-ID: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LGnHMld1jWQW6RYVz0CevvbFzCw Subject: [sfc] comments on draft-song-sfc-legacy-sf-mapping-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, 16 Apr 2014 18:37:48 -0000 To the authors of draft-song-sfc-legacy-sf-mapping: Thank you for contributing this well written draft. I think this is a ver= y worthwhile issue to tackle, but do have some concerns in the current revi= sion of the draft. My specific comments are below. Thanks. Ron Section 2. Terminology * Suggest enhancing your definition of Transparent SF to also state that it= does not inject independent flows into the data stream. For example, som= e transparent HTTP Proxies are not source-ip transparent for some or all of= their upstream connections, instead using their own loopback or interface = IP addresses. Section 3.1.1. Layer 2 MAC Address * Legacy service functions that operate above layer 3 would typically not b= e able to preserve the original SMAC. Take for example the HTTP Proxy, ag= ain. A typical implementation accepts sockets on the client-facing side a= nd binds/connects sockets on the server-facing side. Outgoing packets are= encapsulated with an Ethernet header containing the local MAC address as t= he SMAC. Section 3.1.2. VLAN * This could be problematic in a virtualized environment where the connecti= on from the SFI to the SFE may not be a direct physical connection. An SD= N-based network typically owns the VLAN ID allocations and interpretation. Section 3.1.3. QinQ * Same comment as for VLAN. Section 3.2. For Non-transparent Service Functions * Use of control plane signaling at a packet or flow level would be difficu= lt to scale. From nobody Wed Apr 16 12:17: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 203A31A02EB; Wed, 16 Apr 2014 12:17:52 -0700 (PDT) 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 p8-SbpYMIVhm; Wed, 16 Apr 2014 12:17:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 975F11A02C7; Wed, 16 Apr 2014 12:17:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 12:17:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4NnnrOUGEv14LAKNXCbAd0DaesM Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.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, 16 Apr 2014 19:17:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-04.txt Pages : 18 Date : 2014-04-16 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 instances 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-04 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 nobody Wed Apr 16 14:30: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 8D6631A0366 for ; Wed, 16 Apr 2014 14:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 XCS8MFXPm32n for ; Wed, 16 Apr 2014 14:30:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F0E1D1A0340 for ; Wed, 16 Apr 2014 14:30:52 -0700 (PDT) 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 BDE54800; Wed, 16 Apr 2014 21:30:48 +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; Wed, 16 Apr 2014 22:29:11 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 22:30:47 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Wed, 16 Apr 2014 14:30:41 -0700 From: Lucy yong To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTRUhA6Ab40kaZyfxW4WYVnJsUw7DQ Date: Wed, 16 Apr 2014 21:30:41 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> In-Reply-To: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7VUJdCNafp7Cwa19OJsE4Pwp-Aw Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 16 Apr 2014 21:30:57 -0000 I like the new text about dataplane metadata in section 3.4. Cheers, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, April 16, 2014 2:18 PM To: i-d-announce@ietf.org Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt 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-04.txt Pages : 18 Date : 2014-04-16 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 instances 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 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/ _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 16 18:48: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 273961A001A for ; Wed, 16 Apr 2014 18:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.816 X-Spam-Level: * X-Spam-Status: No, score=1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 TBIgPw5txDVZ for ; Wed, 16 Apr 2014 18:48:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBB11A000E for ; Wed, 16 Apr 2014 18:48:31 -0700 (PDT) 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 BDE68987; Thu, 17 Apr 2014 01:48:27 +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; Thu, 17 Apr 2014 02:46:49 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 02:48:25 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 09:48:22 +0800 From: Xuxiaohu To: Ron Parker , "sfc@ietf.org" Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-00 Thread-Index: Ac9ZoN/oYzcTbeM+TgGZjuhgeN0QeQAOEnVQ Date: Thu, 17 Apr 2014 01:48:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826BD18@NKGEML512-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.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pXVN6ex71xS2vWQZ8kvrNOtEYgI Subject: [sfc] =?gb2312?b?tPC4tDogY29tbWVudHMgb24gZHJhZnQtc29uZy1zZmMtbGVn?= =?gb2312?b?YWN5LXNmLW1hcHBpbmctMDA=?= 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, 17 Apr 2014 01:48:34 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFJvbiBQYXJrZXINCj4gt6LLzcqxvOQ6IDIwMTTE6jTUwjE3yNUgMjoz OA0KPiDK1bz+yMs6IHNmY0BpZXRmLm9yZw0KPiDW98ziOiBbc2ZjXSBjb21tZW50cyBvbiBkcmFm dC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMA0KPiANCj4gVG8gdGhlIGF1dGhvcnMgb2Yg ZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmc6DQo+IA0KPiBUaGFuayB5b3UgZm9yIGNv bnRyaWJ1dGluZyB0aGlzIHdlbGwgd3JpdHRlbiBkcmFmdC4gICBJIHRoaW5rIHRoaXMgaXMgYSB2 ZXJ5DQo+IHdvcnRod2hpbGUgaXNzdWUgdG8gdGFja2xlLCBidXQgZG8gaGF2ZSBzb21lIGNvbmNl cm5zIGluIHRoZSBjdXJyZW50IHJldmlzaW9uIG9mDQo+IHRoZSBkcmFmdC4gICBNeSBzcGVjaWZp YyBjb21tZW50cyBhcmUgYmVsb3cuDQo+IA0KPiBUaGFua3MuDQo+IA0KPiAgICAgUm9uDQo+IA0K PiANCj4gDQo+IA0KPiBTZWN0aW9uIDIuIFRlcm1pbm9sb2d5DQo+IA0KPiAqIFN1Z2dlc3QgZW5o YW5jaW5nIHlvdXIgZGVmaW5pdGlvbiBvZiBUcmFuc3BhcmVudCBTRiB0byBhbHNvIHN0YXRlIHRo YXQgaXQgZG9lcw0KPiBub3QgaW5qZWN0IGluZGVwZW5kZW50IGZsb3dzIGludG8gdGhlIGRhdGEg c3RyZWFtLiAgIEZvciBleGFtcGxlLCBzb21lDQo+IHRyYW5zcGFyZW50IEhUVFAgUHJveGllcyBh cmUgbm90IHNvdXJjZS1pcCB0cmFuc3BhcmVudCBmb3Igc29tZSBvciBhbGwgb2YgdGhlaXINCj4g dXBzdHJlYW0gY29ubmVjdGlvbnMsIGluc3RlYWQgdXNpbmcgdGhlaXIgb3duIGxvb3BiYWNrIG9y IGludGVyZmFjZSBJUA0KPiBhZGRyZXNzZXMuDQoNCkkgYWdyZWUgdGhhdCBubyBpbmplY3Rpb24g b2YgYWRkaXRpb25hbCBmbG93cyBzaG91bGQgYmUgYW5vdGhlciByZXF1aXJlbWVudCBmb3IgdHJh bnNwYXJlbnQgU0YuIEhvd2V2ZXIsIEkgdGhpbmsgdGhlIHRyYW5zcGFyZW50IGxlZ2FjeSBTRiB3 aGljaCBpcyBhcHBsaWNhYmxlIGZvciBzZXJ2aWNlIGNoYWluIHNob3VsZCBhdCBsZWFzdCBtZWV0 IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6IG5vIGNoYW5nZSB0byB0aGUgNS10dXBsZSBvZiB0 aGUgb3JpZ2luYWwgcGFja2V0LiBPdGhlcndpc2UsIGl0IHdvdWxkIGJlIHZlcnkgaGFyZCBvciBl dmVuIGltcG9zc2libGUgZm9yIHRoZSBTRkYgdG8gZG8gdGhlIG1hcHBpbmcgd2l0aG91dCB0aGUg YXNzaXN0YW5jZSBmcm9tIHRoZSBTRiAoZS5nLiwgcHJvdmlkZSB0aGUgbWFwcGluZ3MgY3JlYXRl ZCBvbiB0aGUgU0YgdG8gdGhlIFNGRikuIEdpdmVuIHRoZSBhYm92ZSByZXF1aXJlbWVudCBoYXMg YmVlbiBtZXQsIHdoeSBub3QgZGlyZWN0bHkgdXNlIHRoZSA1LXR1cGxlIGZvciB0aGUgbWFwcGlu ZyBwdXJwb3NlPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBTZWN0aW9uIDMuMS4xLiBM YXllciAyIE1BQyBBZGRyZXNzDQo+IA0KPiAqIExlZ2FjeSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0 IG9wZXJhdGUgYWJvdmUgbGF5ZXIgMyB3b3VsZCB0eXBpY2FsbHkgbm90IGJlIGFibGUNCj4gdG8g cHJlc2VydmUgdGhlIG9yaWdpbmFsIFNNQUMuICAgVGFrZSBmb3IgZXhhbXBsZSB0aGUgSFRUUCBQ cm94eSwgYWdhaW4uICAgQQ0KPiB0eXBpY2FsIGltcGxlbWVudGF0aW9uIGFjY2VwdHMgc29ja2V0 cyBvbiB0aGUgY2xpZW50LWZhY2luZyBzaWRlIGFuZA0KPiBiaW5kcy9jb25uZWN0cyBzb2NrZXRz IG9uIHRoZSBzZXJ2ZXItZmFjaW5nIHNpZGUuICAgT3V0Z29pbmcgcGFja2V0cyBhcmUNCj4gZW5j YXBzdWxhdGVkIHdpdGggYW4gRXRoZXJuZXQgaGVhZGVyIGNvbnRhaW5pbmcgdGhlIGxvY2FsIE1B QyBhZGRyZXNzIGFzIHRoZQ0KPiBTTUFDLg0KPiANCj4gDQo+IA0KPiBTZWN0aW9uIDMuMS4yLiBW TEFODQo+IA0KPiAqIFRoaXMgY291bGQgYmUgcHJvYmxlbWF0aWMgaW4gYSB2aXJ0dWFsaXplZCBl bnZpcm9ubWVudCB3aGVyZSB0aGUgY29ubmVjdGlvbg0KPiBmcm9tIHRoZSBTRkkgdG8gdGhlIFNG RSBtYXkgbm90IGJlIGEgZGlyZWN0IHBoeXNpY2FsIGNvbm5lY3Rpb24uICAgQW4NCj4gU0ROLWJh c2VkIG5ldHdvcmsgdHlwaWNhbGx5IG93bnMgdGhlIFZMQU4gSUQgYWxsb2NhdGlvbnMgYW5kIGlu dGVycHJldGF0aW9uLg0KPiANCj4gDQo+IA0KPiBTZWN0aW9uIDMuMS4zLiBRaW5RDQo+IA0KPiAq IFNhbWUgY29tbWVudCBhcyBmb3IgVkxBTi4NCj4gDQo+IA0KPiANCj4gU2VjdGlvbiAzLjIuICBG b3IgTm9uLXRyYW5zcGFyZW50IFNlcnZpY2UgRnVuY3Rpb25zDQo+IA0KPiAqIFVzZSBvZiBjb250 cm9sIHBsYW5lIHNpZ25hbGluZyBhdCBhIHBhY2tldCBvciBmbG93IGxldmVsIHdvdWxkIGJlIGRp ZmZpY3VsdCB0bw0KPiBzY2FsZS4NCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2Zj QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu Apr 17 01:15: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 5929E1A01C8 for ; Thu, 17 Apr 2014 01:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 2fXvkOxfDN52 for ; Thu, 17 Apr 2014 01:15:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F3BEF1A01FA for ; Thu, 17 Apr 2014 01:15:00 -0700 (PDT) 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 BDE96951; Thu, 17 Apr 2014 08:14:56 +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, 17 Apr 2014 09:13:11 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 09:14:49 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.202]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 16:14:45 +0800 From: "Hongyu Li (Julio)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTKKoP34zgaUiBl7TCyzUwSJsUPM6AgAE3bPA= Date: Thu, 17 Apr 2014 08:14:45 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9E2E5F@SZXEMA509-MBX.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ApFWsUn270i8ZHEPNp2KB5L5j2c Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 08:15:08 -0000 SSBoYXZlIGEgdG90YWxseSBkaWZmZXJlbnQgdmlldyBvbiBtZXRhZGF0YSB0ZXh0LiBCZWZvcmUg d2UsIHRoZSBTRkMgV0csIGdldCBxdWl0ZSBjbGVhciBvZiB0aGUgcHVycG9zZSBvZiBtZXRhZGF0 YSwgaG93IGNvdWxkIHNvbWUgcG9zc2libGUgdXNhZ2UgYmUgZXhjbHVkZWQgYXQgc3VjaCBhbiBl YXJseSBzdGFnZS4gQW5kIHdoeSBhIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0IGxpbWl0cyBwb3Nz aWJsZSBjYXBhYmlsaXRpZXMgb2YgdGhlIHByb3RvY29sLg0KDQpTZWN0aW9uIDQuNi4gU0ZDIG92 ZXIgU2VydmljZSBQYXRoIEZvcmtpbmcgaW4gZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMtMDQgcHJv dmlkZXMgYSB1c2UgY2FzZSB0aGF0IG1ldGFkYXRhIG1heSBiZSByZXF1aXJlZCB0byBjYXJyeSBp bmZvcm1hdGlvbiBmb3IgZGVjaXNpb24gb2YgZm9yd2FyZGluZyBwYXRocy4NCg0KSG9uZ3l1DQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2VudDogVGh1cnNkYXksIEFwcmls IDE3LCAyMDE0IDU6MzEgQU0NClRvOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNC50eHQNCg0KSSBs aWtlIHRoZSBuZXcgdGV4dCBhYm91dCBkYXRhcGxhbmUgbWV0YWRhdGEgaW4gc2VjdGlvbiAzLjQu DQoNCkNoZWVycywNCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE2LCAyMDE0IDI6MTggUE0NClRv OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KDQoN CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoN CiAgICAgICAgVGl0bGUgICAgICAgICAgIDogU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBQcm9i bGVtIFN0YXRlbWVudA0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBQYXVsIFF1aW5uDQogICAg ICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBOYWRlYXUNCglGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNC50eHQNCglQYWdlcyAgICAgICAgICAg OiAxOA0KCURhdGUgICAgICAgICAgICA6IDIwMTQtMDQtMTYNCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IHByb3ZpZGVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3 aXRoIHRoZQ0KICAgZGVwbG95bWVudCBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyAoc3VjaCBhcyBmaXJl d2FsbHMsIGxvYWQgYmFsYW5jZXJzKQ0KICAgaW4gbGFyZ2Utc2NhbGUgZW52aXJvbm1lbnRzLiAg VGhlIHRlcm0gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcw0KICAgdXNlZCB0byBkZXNjcmli ZSB0aGUgZGVmaW5pdGlvbiBhbmQgaW5zdGFudGlhdGlvbiBvZiBhbiBvcmRlcmVkIHNldA0KICAg b2YgaW5zdGFuY2VzIG9mIHN1Y2ggc2VydmljZSBmdW5jdGlvbnMsIGFuZCB0aGUgc3Vic2VxdWVu dCAic3RlZXJpbmciDQogICBvZiB0cmFmZmljIGZsb3dzIHRocm91Z2ggdGhvc2Ugc2VydmljZSBm dW5jdGlvbnMuDQoNCiAgIFRoZSBzZXQgb2YgZW5hYmxlZCBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu cyByZWZsZWN0IG9wZXJhdG9yIHNlcnZpY2UNCiAgIG9mZmVyaW5ncyBhbmQgaXMgZGVzaWduZWQg aW4gY29uanVuY3Rpb24gd2l0aCBhcHBsaWNhdGlvbiBkZWxpdmVyeQ0KICAgYW5kIHNlcnZpY2Ug YW5kIG5ldHdvcmsgcG9saWN5Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVk IHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQNCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMg bWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu Apr 17 06:26: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 C60991A015A for ; Thu, 17 Apr 2014 06:26:14 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 s2g5P9n3sbGC for ; Thu, 17 Apr 2014 06:26:12 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1B1A0150 for ; Thu, 17 Apr 2014 06:26:12 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 06:25:38 -0700 From: Ron Parker To: "Hongyu Li (Julio)" , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiR0m0TUM5mzUi3TWwhCMQdrpsVOEOAgACz84D//+CJQA== Date: Thu, 17 Apr 2014 13:26:07 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E9E2E5F@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E9E2E5F@SZXEMA509-MBX.china.huawei.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IWXCekiIx8beQueE8_C8hOR1_Sg Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 13:26:15 -0000 Hongyu, I took another look at your section 4.6 and agree that it is a valid use ca= se, in general (let's ignore TCP steering complexities for the sake of this= discussion). But perhaps the issue here is terminology. When I look at= that diagram, I think of the DPI function as also containing a reclassifie= r that determines that a new path ID should be followed. With that view,= the forwarding elements (i.e., Service Function Forwarder) aren't reacting= , directly, to the metadata. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Hongyu Li (Julio) Sent: Thursday, April 17, 2014 4:15 AM To: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt I have a totally different view on metadata text. Before we, the SFC WG, ge= t quite clear of the purpose of metadata, how could some possible usage be = excluded at such an early stage. And why a problem statement draft limits p= ossible capabilities of the protocol. Section 4.6. SFC over Service Path Forking in draft-liu-sfc-use-cases-04 pr= ovides a use case that metadata may be required to carry information for de= cision of forwarding paths. Hongyu -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, April 17, 2014 5:31 AM To: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt I like the new text about dataplane metadata in section 3.4. Cheers, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, April 16, 2014 2:18 PM To: i-d-announce@ietf.org Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt 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-04.txt Pages : 18 Date : 2014-04-16 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 instances 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 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/ _______________________________________________ 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 nobody Thu Apr 17 06:35:51 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 DFA321A012A for ; Thu, 17 Apr 2014 06:35:48 -0700 (PDT) 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 UVVeOz3hYID4 for ; Thu, 17 Apr 2014 06:35:46 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAF71A0127 for ; Thu, 17 Apr 2014 06:35:46 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so344534yha.17 for ; Thu, 17 Apr 2014 06:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v1uL8Gcr6R19BZv06UiYmAthkjnIbgJERt973sW/6yI=; b=JCtgBrm1kUprVLmkzfehUGWQRSNpvIZsvtuzyc5Db5cyVxnWRp4L5Romeesc0ZjfkC Z28U3KlxcMz40uWt78MwSRRoO1pfLzWhLjyRSrc76luVch6keE10FP+s7BwhrVIA6DKs 92b0VhMN3vXN/s3lmSrqG7CMRHO+jPX3AZRnSCVTe9VRO2UBPVj3vSeGhyowSwsDYN0/ f+vPPP3ANW3p1uKdHJ3E6tJ4T/nsKqEHcVYgcUKwegTWYmAR/o+WhqMQHEGO1t6buA6G AvyqcVeo+p2WRV5OUFR6n2IIVIJksZ0c05wxklZXMY7obtIlYTqa0AlAX8cJgiVuGX8w tQYA== X-Received: by 10.236.66.3 with SMTP id g3mr22677916yhd.41.1397741742382; Thu, 17 Apr 2014 06:35:42 -0700 (PDT) Received: from [192.168.1.109] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPSA id t42sm48188190yhn.12.2014.04.17.06.35.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 06:35:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPad Mail (11D167) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> Date: Thu, 17 Apr 2014 06:35:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> To: Lucy yong Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4vxyhORappDGaBDgwT4wR4eRAiw Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 13:35:49 -0000 I agree. Text shapes up nicely. Also re-entrant re-classify recursion spelled out for dynamic forks. We are starting to see functions designed with programability in mind that n= eed it. Would like to see the option of metadata as mappable (eid) key at least ment= ioned. While it does require some state savings per flow (sfc is very much a flow t= hing ..), It helps address the different fields that come up, the per packet overhead,= =20 out of band complexity-consistency.. reduces the problem to mapping, something we have to solve anyway in many of the sfc use cases. --szb > On Apr 16, 2014, at 14:30, Lucy yong wrote: >=20 > I like the new text about dataplane metadata in section 3.4. >=20 > Cheers, > Lucy >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.= org > Sent: Wednesday, April 16, 2014 2:18 PM > To: i-d-announce@ietf.org > Cc: sfc@ietf.org > Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Service Function Chaining Working Group o= f the IETF. >=20 > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-04.txt > Pages : 18 > Date : 2014-04-16 >=20 > 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 instances of such service functions, and the subsequent "steering" > of traffic flows through those service functions. >=20 > The set of enabled service function chains reflect operator service > offerings and is designed in conjunction with application delivery > and service and network policy. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 nobody Thu Apr 17 06:49: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 6B3521A0127 for ; Thu, 17 Apr 2014 06:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 TZQFz1n6GftL for ; Thu, 17 Apr 2014 06:49:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 78B5E1A0180 for ; Thu, 17 Apr 2014 06:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3668; q=dns/txt; s=iport; t=1397742558; x=1398952158; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GBjs0GwgkBo2oMh4KwyoBVfMLD1w1sX/Pzkty8U1ji0=; b=fAibqJSNAZ0VQvfaL4JHTyV0xhq4Lc8ZDLdz/P63NKMAW+HI7RR8OtWh b/YMlNzNhPbUTi2BygueQoi06aVBKf/S8uBVwXjaTRcpNKOgKfL1lSAm0 amLfIW1HqmBpfHzoZbvrlRBomi030jsiZFPEGlZzLLJqjwS5z5DO/aZG8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFACfbT1OtJA2L/2dsb2JhbABZgwY7UQa8J4c4gSQWdIIlAQEBBAEBATcrCQsMBAIBCBEEAQEBHgkHIQYLFAkIAgQBDQUJh18DEQgFw3gNhnIXjEmCGQcGhDIElwCBboE3i0aFUIMxgis X-IronPort-AV: E=Sophos;i="4.97,879,1389744000"; d="scan'208";a="36612595" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 17 Apr 2014 13:49:17 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3HDnHVA007991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 13:49:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 08:49:17 -0500 From: "Jim Guichard (jguichar)" To: Sharon , Lucy yong Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiVvOH0jxarUEe3qe87pNfkn5sVFryAgAENnQD//8C4gA== Date: Thu, 17 Apr 2014 13:49:16 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> In-Reply-To: <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.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.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E39A2682D19934F9CDB483A9FE8940D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lFZwDZQbrXYKiUJxUbg_Jis0b7E Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 13:49:25 -0000 Hi Sharon, I would like to just clarify that I understand your second point. I believe you are saying that you would like the data plane metadata to carry pointers (rather than the full metadata structure) that may be used for key access into a more detailed data structure within the SF itself correct?=20 On 4/17/14, 9:35 AM, "Sharon" wrote: >I agree. Text shapes up nicely. >Also re-entrant re-classify recursion spelled out for dynamic forks. >We are starting to see functions designed with programability in mind >that need it. > >Would like to see the option of metadata as mappable (eid) key at least >mentioned. >While it does require some state savings per flow (sfc is very much a >flow thing ..), >It helps address the different fields that come up, the per packet >overhead,=20 >out of band complexity-consistency.. reduces the problem to mapping, >something we have to solve anyway in many of the sfc use cases. > >--szb > >> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>=20 >> I like the new text about dataplane metadata in section 3.4. >>=20 >> Cheers, >> Lucy >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>internet-drafts@ietf.org >> Sent: Wednesday, April 16, 2014 2:18 PM >> To: i-d-announce@ietf.org >> Cc: sfc@ietf.org >> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Service Function Chaining Working >>Group of the IETF. >>=20 >> Title : Service Function Chaining Problem Statement >> Authors : Paul Quinn >> Thomas Nadeau >> Filename : draft-ietf-sfc-problem-statement-04.txt >> Pages : 18 >> Date : 2014-04-16 >>=20 >> 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 instances of such service functions, and the subsequent "steering" >> of traffic flows through those service functions. >>=20 >> The set of enabled service function chains reflect operator service >> offerings and is designed in conjunction with application delivery >> and service and network policy. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Apr 17 06:54:51 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 385091A017D for ; Thu, 17 Apr 2014 06:54:50 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WkjpNMwi9Zm4 for ; Thu, 17 Apr 2014 06:54:46 -0700 (PDT) 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 3D6001A0127 for ; Thu, 17 Apr 2014 06:54:46 -0700 (PDT) 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.0174.001; Thu, 17 Apr 2014 06:54:42 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , Sharon , Lucy yong Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiR0m0TUM5mzUi3TWwhCMQdrpsVOEOAgAENnQCAAAPMAP//i3lA Date: Thu, 17 Apr 2014 13:54:41 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0CgFOeu9MxsHRo5oK7YTDhENVk8 Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 13:54:50 -0000 I think Sharon's use case is very important. But, so long as the interpre= tation of metadata is not prescriptive in the problem statement, wouldn't t= his be more appropriate for the use cases document? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, April 17, 2014 9:49 AM To: Sharon; Lucy yong Cc: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Hi Sharon, I would like to just clarify that I understand your second point. I believe= you are saying that you would like the data plane metadata to carry pointe= rs (rather than the full metadata structure) that may be used for key acces= s into a more detailed data structure within the SF itself correct?=20 On 4/17/14, 9:35 AM, "Sharon" wrote: >I agree. Text shapes up nicely. >Also re-entrant re-classify recursion spelled out for dynamic forks. >We are starting to see functions designed with programability in mind=20 >that need it. > >Would like to see the option of metadata as mappable (eid) key at least=20 >mentioned. >While it does require some state savings per flow (sfc is very much a=20 >flow thing ..), It helps address the different fields that come up, the=20 >per packet overhead, out of band complexity-consistency.. reduces the=20 >problem to mapping, something we have to solve anyway in many of the=20 >sfc use cases. > >--szb > >> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>=20 >> I like the new text about dataplane metadata in section 3.4. >>=20 >> Cheers, >> Lucy >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>internet-drafts@ietf.org >> Sent: Wednesday, April 16, 2014 2:18 PM >> To: i-d-announce@ietf.org >> Cc: sfc@ietf.org >> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Service Function Chaining Working=20 >>Group of the IETF. >>=20 >> Title : Service Function Chaining Problem Statement >> Authors : Paul Quinn >> Thomas Nadeau >> Filename : draft-ietf-sfc-problem-statement-04.txt >> Pages : 18 >> Date : 2014-04-16 >>=20 >> 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 instances of such service functions, and the subsequent "steering" >> of traffic flows through those service functions. >>=20 >> The set of enabled service function chains reflect operator service >> offerings and is designed in conjunction with application delivery >> and service and network policy. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 > >_______________________________________________ >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 nobody Thu Apr 17 07:05: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 DD97A1A019D for ; Thu, 17 Apr 2014 07:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 NfjzukrRlwcE for ; Thu, 17 Apr 2014 07:05:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B23B1A01A8 for ; Thu, 17 Apr 2014 07:05:51 -0700 (PDT) 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 BDF34522; Thu, 17 Apr 2014 14:05:47 +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; Thu, 17 Apr 2014 15:04:21 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 15:05:42 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 07:05:31 -0700 From: Lucy yong To: Ron Parker , "Jim Guichard (jguichar)" , Sharon Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTRUhA6Ab40kaZyfxW4WYVnJsUw7DQgAGCMACAAAPMAIAAAYSA//+NsZA= Date: Thu, 17 Apr 2014 14:05:30 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453714BA@dfweml701-chm.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@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.47.128.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Am5S3kJU6Wm1hznG8_3yUosK6oU Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 14:05:55 -0000 I agree that Sharon's use case is very important. =20 This metadata feature should be captured in the SFC requirement document. I= am surprised in seeing no metadata word mentioned in the requirement doc. = yet. Lucy=20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, April 17, 2014 8:55 AM To: Jim Guichard (jguichar); Sharon; Lucy yong Cc: sfc@ietf.org Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt I think Sharon's use case is very important. But, so long as the interpre= tation of metadata is not prescriptive in the problem statement, wouldn't t= his be more appropriate for the use cases document? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, April 17, 2014 9:49 AM To: Sharon; Lucy yong Cc: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Hi Sharon, I would like to just clarify that I understand your second point. I believe= you are saying that you would like the data plane metadata to carry pointe= rs (rather than the full metadata structure) that may be used for key acces= s into a more detailed data structure within the SF itself correct?=20 On 4/17/14, 9:35 AM, "Sharon" wrote: >I agree. Text shapes up nicely. >Also re-entrant re-classify recursion spelled out for dynamic forks. >We are starting to see functions designed with programability in mind=20 >that need it. > >Would like to see the option of metadata as mappable (eid) key at least=20 >mentioned. >While it does require some state savings per flow (sfc is very much a=20 >flow thing ..), It helps address the different fields that come up, the=20 >per packet overhead, out of band complexity-consistency.. reduces the=20 >problem to mapping, something we have to solve anyway in many of the=20 >sfc use cases. > >--szb > >> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>=20 >> I like the new text about dataplane metadata in section 3.4. >>=20 >> Cheers, >> Lucy >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>internet-drafts@ietf.org >> Sent: Wednesday, April 16, 2014 2:18 PM >> To: i-d-announce@ietf.org >> Cc: sfc@ietf.org >> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Service Function Chaining Working=20 >>Group of the IETF. >>=20 >> Title : Service Function Chaining Problem Statement >> Authors : Paul Quinn >> Thomas Nadeau >> Filename : draft-ietf-sfc-problem-statement-04.txt >> Pages : 18 >> Date : 2014-04-16 >>=20 >> 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 instances of such service functions, and the subsequent "steering" >> of traffic flows through those service functions. >>=20 >> The set of enabled service function chains reflect operator service >> offerings and is designed in conjunction with application delivery >> and service and network policy. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 > >_______________________________________________ >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 nobody Thu Apr 17 07:12:51 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 1A4A71A0180; Thu, 17 Apr 2014 07:12:49 -0700 (PDT) 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 ddWWAcUK5804; Thu, 17 Apr 2014 07:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAB21A0043; Thu, 17 Apr 2014 07:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417141244.30896.19047.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 07:12:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/y2FU8-Pocbb6YymxNkRVNv_ZsJw Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-05.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: Thu, 17 Apr 2014 14:12:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-05.txt Pages : 18 Date : 2014-04-17 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 instances 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-05 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 nobody Thu Apr 17 09:41: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 8022D1A02B6 for ; Thu, 17 Apr 2014 09:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 EDSQa235jfCc for ; Thu, 17 Apr 2014 09:40:56 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B74551A024F for ; Thu, 17 Apr 2014 09:40:55 -0700 (PDT) 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 <0N46009UOP03UT@tid.hi.inet> for sfc@ietf.org; Thu, 17 Apr 2014 18:40:51 +0200 (MEST) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 24.22.03703.31400535; Thu, 17 Apr 2014 18:40:51 +0200 (CEST) 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 <0N46009UIP02UT@tid.hi.inet> for sfc@ietf.org; Thu, 17 Apr 2014 18:40:51 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.153]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 18:40:50 +0200 Date: Thu, 17 Apr 2014 16:40:50 +0000 From: "Diego R. Lopez" In-reply-to: <2691CE0099834E4A9C5044EEC662BB9D453714BA@dfweml701-chm.china.huawei.com> X-Originating-IP: [10.95.64.115] To: Lucy yong Message-id: Content-id: <39FE90A40271544D9335324F69B10FF1@hi.inet> 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] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-index: AQHPWaiUl4goxLBeoUyr/NeQR6BY/JsUoWOAgAENnQCAAAPNAIAAAYOAgAADBgCAACswgA== X-AuditID: 0a5f4068-f79636d000000e77-49-535004139ac8 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsXCFe/ApSvMEhBscGETv8WTB1vZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eFYN1PBC7uK+Zd2sDYwzrDtYuTkkBAwkWg7sooJwhaTuHBv PVsXIxeHkMBBRolXr1ayQzjfGCU29D6AysxklJi68TMLSAuLgKrE3ptT2EBsNiD7UfNvdhBb WMBNYk/LUqCxHBycAhESO7bVQmxQkPhz7jFYq4iAisSXa2sYQWYyC8xnlHi+sRvsDF4BS4l1 /7rBZjILmEnc6Wxmg4gLSvyYfI8FZCazgLrElCm5ECXiEs2tN1kgbEWJaYsaGEFsRgFZiXfz 57NC7HKX+HfiJdTeCIlL99ewQNwjILFkz3lmCFtU4uXjf6wQPzYzSyybcZplAqPELCRnzEJy xiyEM2YhOWMWkjMWMLKuYhQrTirKTM8oyU3MzEk3MNTLyNTLzEst2cQIibuMHYzLd6ocYhTg YFTi4RVg8g8WYk0sK67MPcQowcGsJMLr8hgoxJuSWFmVWpQfX1Sak1p8iFGag0VJnDfudVGA kEB6YklqdmpqQWoRTJaJg1OqgdFGesdC4UlMhx7wBU91rsjkYj8n8XXaooQDxefcfnEmeHLH vF4n7zdXjT3s+cPzj23lma97L35e+90sXixx7r29+4yebuKIyFnDzClvFL9bepdCu9Hq/D7p zzPeCG1cHR5WPKmi5JDsg+tsis+uWn+WDNff/a36zMytR9Kc9v9PlDqy+K7Y2YVKLMUZiYZa zEXFiQA1zdiXtwIAAA== References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D453714BA@dfweml701-chm.china.huawei.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gwDINWaHLuaBEJ6Kyt-YX6aEHsk Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" , Sharon , Ron Parker Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 16:41:01 -0000 V2hlbiB0aGlua2luZyBhYm91dCBtZXRhZGF0YSwgSSBoYXZlIGFsd2F5cyBoYWQgdGhlIG1hcHBp bmcgU2hhcm9uIG1lbnRpb25zIGluIG1pbmQuIEJ1dCBJIGFncmVlIHRoYXQgcHJvYmFibHkgdGhl IHByb2JsZW0gc3RhdGVtZW50IGlzIG5vdCB0aGUgbW9zdCBhcHByb3ByaWF0ZSBwbGFjZSBmb3Ig c3RhdGluZyBpdC4NCg0KQmUgZ29vZGUsDQoNCk9uIDE3IEFwciAyMDE0LCBhdCAxNjowNSAsIEx1 Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+IEkgYWdyZWUgdGhhdCBT aGFyb24ncyB1c2UgY2FzZSBpcyB2ZXJ5IGltcG9ydGFudC4NCj4NCj4gVGhpcyBtZXRhZGF0YSBm ZWF0dXJlIHNob3VsZCBiZSBjYXB0dXJlZCBpbiB0aGUgU0ZDIHJlcXVpcmVtZW50IGRvY3VtZW50 LiBJIGFtIHN1cnByaXNlZCBpbiBzZWVpbmcgbm8gbWV0YWRhdGEgd29yZCBtZW50aW9uZWQgaW4g dGhlIHJlcXVpcmVtZW50IGRvYy4geWV0Lg0KPg0KPiBMdWN5DQo+DQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTcsIDIwMTQgODo1NSBB TQ0KPiBUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IFNoYXJvbjsgTHVjeSB5b25nDQo+IENj OiBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzZmNdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KPg0KPiBJIHRoaW5rIFNoYXJvbidzIHVz ZSBjYXNlIGlzIHZlcnkgaW1wb3J0YW50LiAgIEJ1dCwgc28gbG9uZyBhcyB0aGUgaW50ZXJwcmV0 YXRpb24gb2YgbWV0YWRhdGEgaXMgbm90IHByZXNjcmlwdGl2ZSBpbiB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQsIHdvdWxkbid0IHRoaXMgYmUgbW9yZSBhcHByb3ByaWF0ZSBmb3IgdGhlIHVzZSBjYXNl cyBkb2N1bWVudD8NCj4NCj4gICBSb24NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTcsIDIw MTQgOTo0OSBBTQ0KPiBUbzogU2hhcm9uOyBMdWN5IHlvbmcNCj4gQ2M6IHNmY0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW3NmY10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1z dGF0ZW1lbnQtMDQudHh0DQo+DQo+IEhpIFNoYXJvbiwNCj4NCj4gSSB3b3VsZCBsaWtlIHRvIGp1 c3QgY2xhcmlmeSB0aGF0IEkgdW5kZXJzdGFuZCB5b3VyIHNlY29uZCBwb2ludC4gSSBiZWxpZXZl IHlvdSBhcmUgc2F5aW5nIHRoYXQgeW91IHdvdWxkIGxpa2UgdGhlIGRhdGEgcGxhbmUgbWV0YWRh dGEgdG8gY2FycnkgcG9pbnRlcnMgKHJhdGhlciB0aGFuIHRoZSBmdWxsIG1ldGFkYXRhIHN0cnVj dHVyZSkgdGhhdCBtYXkgYmUgdXNlZCBmb3Iga2V5IGFjY2VzcyBpbnRvIGEgbW9yZSBkZXRhaWxl ZCBkYXRhIHN0cnVjdHVyZSB3aXRoaW4gdGhlIFNGIGl0c2VsZiBjb3JyZWN0Pw0KPg0KPiBPbiA0 LzE3LzE0LCA5OjM1IEFNLCAiU2hhcm9uIiA8c2JhcmthaUBnbWFpbC5jb20+IHdyb3RlOg0KPg0K Pj4gSSBhZ3JlZS4gVGV4dCBzaGFwZXMgdXAgbmljZWx5Lg0KPj4gQWxzbyByZS1lbnRyYW50IHJl LWNsYXNzaWZ5IHJlY3Vyc2lvbiBzcGVsbGVkIG91dCBmb3IgZHluYW1pYyBmb3Jrcy4NCj4+IFdl IGFyZSBzdGFydGluZyB0byBzZWUgZnVuY3Rpb25zIGRlc2lnbmVkIHdpdGggcHJvZ3JhbWFiaWxp dHkgaW4gbWluZA0KPj4gdGhhdCBuZWVkIGl0Lg0KPj4NCj4+IFdvdWxkIGxpa2UgdG8gc2VlIHRo ZSBvcHRpb24gb2YgbWV0YWRhdGEgYXMgbWFwcGFibGUgKGVpZCkga2V5IGF0IGxlYXN0DQo+PiBt ZW50aW9uZWQuDQo+PiBXaGlsZSBpdCBkb2VzIHJlcXVpcmUgc29tZSBzdGF0ZSBzYXZpbmdzIHBl ciBmbG93IChzZmMgaXMgdmVyeSBtdWNoIGENCj4+IGZsb3cgdGhpbmcgLi4pLCBJdCBoZWxwcyBh ZGRyZXNzIHRoZSBkaWZmZXJlbnQgZmllbGRzIHRoYXQgY29tZSB1cCwgdGhlDQo+PiBwZXIgcGFj a2V0IG92ZXJoZWFkLCBvdXQgb2YgYmFuZCBjb21wbGV4aXR5LWNvbnNpc3RlbmN5Li4gcmVkdWNl cyB0aGUNCj4+IHByb2JsZW0gdG8gbWFwcGluZywgc29tZXRoaW5nIHdlIGhhdmUgdG8gc29sdmUg YW55d2F5IGluIG1hbnkgb2YgdGhlDQo+PiBzZmMgdXNlIGNhc2VzLg0KPj4NCj4+IC0tc3piDQo+ Pg0KPj4+IE9uIEFwciAxNiwgMjAxNCwgYXQgMTQ6MzAsIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1 YXdlaS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4gSSBsaWtlIHRoZSBuZXcgdGV4dCBhYm91dCBkYXRh cGxhbmUgbWV0YWRhdGEgaW4gc2VjdGlvbiAzLjQuDQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4gTHVj eQ0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+Pj4gaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAxNCAyOjE4IFBN DQo+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPj4+IENjOiBzZmNAaWV0Zi5vcmcNCj4+ PiBTdWJqZWN0OiBbc2ZjXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRl bWVudC0wNC50eHQNCj4+Pg0KPj4+DQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj4gZGlyZWN0b3JpZXMuDQo+ Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZyBXb3JraW5nDQo+Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4NCj4+PiAgICAgICBUaXRs ZSAgICAgICAgICAgOiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIFByb2JsZW0gU3RhdGVtZW50 DQo+Pj4gICAgICAgQXV0aG9ycyAgICAgICAgIDogUGF1bCBRdWlubg0KPj4+ICAgICAgICAgICAg ICAgICAgICAgICAgIFRob21hcyBOYWRlYXUNCj4+PiAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KPj4+ICAgUGFnZXMgICAgICAgICAg IDogMTgNCj4+PiAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDQtMTYNCj4+Pg0KPj4+IEFic3Ry YWN0Og0KPj4+ICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBpc3N1 ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPj4+ICBkZXBsb3ltZW50IG9mIHNlcnZpY2UgZnVuY3Rp b25zIChzdWNoIGFzIGZpcmV3YWxscywgbG9hZCBiYWxhbmNlcnMpDQo+Pj4gIGluIGxhcmdlLXNj YWxlIGVudmlyb25tZW50cy4gIFRoZSB0ZXJtIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaXMN Cj4+PiAgdXNlZCB0byBkZXNjcmliZSB0aGUgZGVmaW5pdGlvbiBhbmQgaW5zdGFudGlhdGlvbiBv ZiBhbiBvcmRlcmVkIHNldA0KPj4+ICBvZiBpbnN0YW5jZXMgb2Ygc3VjaCBzZXJ2aWNlIGZ1bmN0 aW9ucywgYW5kIHRoZSBzdWJzZXF1ZW50ICJzdGVlcmluZyINCj4+PiAgb2YgdHJhZmZpYyBmbG93 cyB0aHJvdWdoIHRob3NlIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+DQo+Pj4gIFRoZSBzZXQgb2Yg ZW5hYmxlZCBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlucyByZWZsZWN0IG9wZXJhdG9yIHNlcnZpY2UN Cj4+PiAgb2ZmZXJpbmdzIGFuZCBpcyBkZXNpZ25lZCBpbiBjb25qdW5jdGlvbiB3aXRoIGFwcGxp Y2F0aW9uIGRlbGl2ZXJ5DQo+Pj4gIGFuZCBzZXJ2aWNlIGFuZCBuZXR3b3JrIHBvbGljeS4NCj4+ Pg0KPj4+DQo+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z ZmMtcHJvYmxlbS1zdGF0ZW1lbnQvDQo+Pj4NCj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPj4+DQo+Pj4gQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0DQo+Pj4N Cj4+Pg0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+Pj4N Cj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pg0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+PiBzZmNAaWV0Zi5v cmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMg bWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QN Cj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoN CkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMv ZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5 IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4g UHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24g ZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0K VGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBX ZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBz ZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgN Cg== From nobody Thu Apr 17 10:09: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 6A87D1A0330 for ; Thu, 17 Apr 2014 10:08:51 -0700 (PDT) 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 o02ALA3woLxs for ; Thu, 17 Apr 2014 10:08:48 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 61D2F1A00FE for ; Thu, 17 Apr 2014 10:08:40 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id p10so573247pdj.3 for ; Thu, 17 Apr 2014 10:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=idpDU22BDqY9GphTFBeNz+2HlPGNp50UZFGW8zxchd0=; b=sz0cBKQplN8BWSpqHfgTAjkTywrec5Os++B0o22VhcT2ING3szbwIX0SNPAWaCUIYf NlOLHoSbjcFYHqvb7C91//myrUVf1XOYiuq46b5N3/Ki23wNSOa/oomEkR44mDiOwOSn OweCgPmrIdZIC2wF/VeORci63fy0C1O3C+wwQNTSZ2pDlPilmJV7NZJrZD2Fv73tDiU4 91Rdumb4QArt5IdLOQ4niVHPTa9H8PRVM3NncyXXRPRZSm6e3clViAqvviCdimz14GOG U5jNwYbT+ZfahyXZyNQXNUiS4+uK9kCN9d8WUlYlWJUvWMhc4bLu8qTMP/X6leef+MoH jF5A== X-Received: by 10.68.133.229 with SMTP id pf5mr16877716pbb.115.1397754516850; Thu, 17 Apr 2014 10:08:36 -0700 (PDT) Received: from [192.168.1.215] ([157.22.28.27]) by mx.google.com with ESMTPSA id av2sm54709387pbc.16.2014.04.17.10.08.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 10:08:36 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 From: SHARON BARKAI In-Reply-To: Date: Thu, 17 Apr 2014 10:01:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1816) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ITTE9Y3PK6nxVi4twr-kjtvu0-s Cc: "sfc@ietf.org" , Lucy yong Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 17 Apr 2014 17:08:53 -0000 yes, its a (tough) challenge we see more of - namely local forwarding decision based on a global context. other examples are in the nvo3 and segment routing use cases. mapping authority (via a key pointer) isn=92t a magic solution, but at least it consolidates the chalange for multiple wg cases, it can stay away from union type or complex TLV fields per packet, and addresses inline/out-of-band race-consitency-releilecy-awarness = issues Lucy and Joel raised. i wouldn=92t spell it out in the problem statemet doc, but would mention the pointer option when introducing metadata.=20 On Apr 17, 2014, at 6:49 AM, Jim Guichard (jguichar) = wrote: > Hi Sharon, >=20 > I would like to just clarify that I understand your second point. I > believe you are saying that you would like the data plane metadata to > carry pointers (rather than the full metadata structure) that may be = used > for key access into a more detailed data structure within the SF = itself > correct?=20 >=20 > On 4/17/14, 9:35 AM, "Sharon" wrote: >=20 >> I agree. Text shapes up nicely. >> Also re-entrant re-classify recursion spelled out for dynamic forks. >> We are starting to see functions designed with programability in mind >> that need it. >>=20 >> Would like to see the option of metadata as mappable (eid) key at = least >> mentioned. >> While it does require some state savings per flow (sfc is very much a >> flow thing ..), >> It helps address the different fields that come up, the per packet >> overhead,=20 >> out of band complexity-consistency.. reduces the problem to mapping, >> something we have to solve anyway in many of the sfc use cases. >>=20 >> --szb >>=20 >>> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>>=20 >>> I like the new text about dataplane metadata in section 3.4. >>>=20 >>> Cheers, >>> Lucy >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> Sent: Wednesday, April 16, 2014 2:18 PM >>> To: i-d-announce@ietf.org >>> Cc: sfc@ietf.org >>> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Service Function Chaining Working >>> Group of the IETF. >>>=20 >>> Title : Service Function Chaining Problem Statement >>> Authors : Paul Quinn >>> Thomas Nadeau >>> Filename : draft-ietf-sfc-problem-statement-04.txt >>> Pages : 18 >>> Date : 2014-04-16 >>>=20 >>> 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 instances of such service functions, and the subsequent = "steering" >>> of traffic flows through those service functions. >>>=20 >>> The set of enabled service function chains reflect operator service >>> offerings and is designed in conjunction with application delivery >>> and service and network policy. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04= >>>=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 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=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 >=20 From nobody Fri Apr 18 02:00: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 BE2461A00CD; Fri, 18 Apr 2014 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 1YKKh8mINA83; Fri, 18 Apr 2014 02:00:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B31A001B; Fri, 18 Apr 2014 02:00:41 -0700 (PDT) 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 BDG14192; Fri, 18 Apr 2014 09:00:37 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 09:58:55 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 10:00:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Apr 2014 17:00:28 +0800 From: Xuxiaohu To: "sfc@ietf.org" Thread-Topic: Why Transport Dependence is deemed as a problem?//re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTBvmFbElTWEybzBPXXbCPGZsVEbjw Date: Fri, 18 Apr 2014 09:00:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> In-Reply-To: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/olWvTufwiWYFdke8GOt4LhZn-J4 Cc: "spring@ietf.org" Subject: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-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: Fri, 18 Apr 2014 09:00:44 -0000 SGkgYWxsLA0KDQpJdCBzYWlkIGluIHNlY3Rpb24gMi42LiAgVHJhbnNwb3J0IERlcGVuZGVuY2Ug b2YgdGhlIFBTIGRyYWZ0Og0KDQogICJTZXJ2aWNlIGZ1bmN0aW9ucyBjYW4gYW5kIHdpbGwgYmUg ZGVwbG95ZWQgaW4gbmV0d29ya3Mgd2l0aCBhIHJhbmdlDQogICBvZiB0cmFuc3BvcnRzLCBpbmNs dWRpbmcgdW5kZXIgYW5kIG92ZXJsYXlzLiAgVGhlIGNvdXBsaW5nIG9mIHNlcnZpY2UNCiAgIGZ1 bmN0aW9ucyB0byB0b3BvbG9neSByZXF1aXJlcyBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBzdXBwb3J0 IG1hbnkNCiAgIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9ucyBvciBmb3IgYSB0cmFuc3BvcnQgZ2F0 ZXdheSBmdW5jdGlvbiB0byBiZQ0KICAgcHJlc2VudC4iDQoNCkFzc3VtZSB0aGUgZnVuY3Rpb24g b2Ygc2VydmljZSBjaGFpbiBjYW4gYmUgZGl2aWRlZCBpbnRvIHR3byBsYXllcnM6IG9uZSBpcyB0 aGUgc2VydmljZSBwYXRoIGxheWVyIHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBzdGVlcmluZyB0 aGUgcGFja2V0cyBhbG9uZyB0aGUgc2VydmljZSBwYXRoLCB0aGUgb3RoZXIgaXMgdGhlIHNlcnZp Y2UgZnVuY3Rpb24gbGF5ZXIgd2hpY2ggaXMgcmVzcG9uc2libGUgZm9yIGFwcGx5aW5nIGEgZ2l2 ZW4gc2VydmljZSB0byB0aGUgcGFja2V0LiBJIGFncmVlIHRoYXQgdHJhbnNwb3J0IGRlcGVuZGVu Y2UgaXMgYmFkIGZvciB0aGUgc2VydmljZSBmdW5jdGlvbiBsYXllci4gSG93ZXZlciwgSSBkb24n dCB1bmRlcnN0YW5kIHdoeSB0cmFuc3BvcnQgZGVwZW5kZW5jZSBpcyBhbHNvIGJhZCBmb3IgdGhl IHNlcnZpY2UgcGF0aCBsYXllci4gSW4gZmFjdCwgdGhlcmUgYXJlIG9ubHkgdHdvIHVuZGVybGF5 IHRyYW5zcG9ydHMgKGkuZS4sIElQIGFuZCBNUExTKSB3aGljaCBuZWVkIHRvIGJlIGNvbnNpZGVy ZWQgZm9yIHNlcnZpY2UgY2hhaW4uIFRoZXJlZm9yZSwgd2UganVzdCBuZWVkIHRvIGxldmVyYWdl IHRoZSBzb3VyY2Ugcm91dGluZyBjYXBhYmlsaXR5IGFzc29jaWF0ZWQgd2l0aCBJUCBvciBNUExT IHRvIHJlYWxpemUgdGhlIGZ1bmN0aW9uIG9mIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIuIFRoYXQn cyB0byBzYXksIHdlIGNhbiB1c2UgYW4gb3JkZXJlZCBsaXN0IG9mIElQIGFkZHJlc3NlcyBvciBN UExTIGxhYmVscyBjYXJyaWVkIGluIHRoZSBwYWNrZXQgdG8gcmVwcmVzZW50IHRoZSBzZXJ2aWNl IHBhdGguIEEgTVBMUyBsYWJlbCBpbiB0aGUgb3JkZXJlZCBsaXN0IG9mIE1QTFMgbGFiZWxzIChp LmUuLCBhIE1QTFMgbGFiZWwgc3RhY2spIG9yIGFuIElQIGFkZHJlc3MgaW4gdGhlIG9yZGVyZWQg bGlzdCBvZiBJUCBhZGRyZXNzZXMgY2FuIGJlIHVzZWQgdG8gaW5kaWNhdGUgZWl0aGVyIGEgc2Vy dmljZSBub2RlIHdpdGhpbiB0aGUgc2VydmljZSBwYXRoIG9yIGEgc2VydmljZSBmdW5jdGlvbiBv biBhIGdpdmVuIHNlcnZpY2Ugbm9kZS4gTm90ZSB0aGF0IE1QTFMgbGFiZWxzIGFuZCBJUCBhZGRy ZXNzZXMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSB1c2VkIGZvciBpbmRpY2F0aW5nIHNlcnZpY2Vz IChlLmcuLCBWUE4gbGFiZWxzIGFuZCBtdWx0aWNhc3QgYWRkcmVzc2VzIGluIHRoZSByYW5nZSBv ZiAyMjQuMC4wLnggb3IgRkYwMjo6eCApLiANCg0KT2YgY291cnNlLCBpZiB5b3Ugc3RpbGwgdGhp bmsgdGhlcmUgYXJlIHRvbyBtdWNoIHdvcmsgdG8gZG8sIHlvdSBjb3VsZCBhY3R1YWxseSBvbmx5 IGNvbnNpZGVyIHRoZSBNUExTLWJhc2VkIGFwcHJvYWNoIChpLmUuLCB1c2luZyBhIE1QTFMgbGFi ZWwgc3RhY2sgdG8gcmVwcmVzZW50IGEgc2VydmljZSBwYXRoKSBzaW5jZSBpdCBjb3VsZCBhbHNv IGJlIGFwcGxpY2FibGUgaW4gYm90aCBJUHY0IGFuZCBJUHY2IG5ldHdvcmtzIHdpdGggdGhlIGhl bHAgb2YgYW55IGtpbmQgb2YgTVBMUyBvdmVyIElQIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9naWVz LiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcNCj4gt6LLzcqxvOQ6IDIwMTTE6jTUwjE3yNUgMzoxOA0KPiDK1bz+yMs6 IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiCzrcvNOiBzZmNAaWV0Zi5vcmcNCj4g1vfM4jogW3Nm Y10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+ IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBXb3JraW5nIEdyb3VwIG9mIHRo ZQ0KPiBJRVRGLg0KPiANCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nIFByb2JsZW0gU3RhdGVtZW50DQo+ICAgICAgICAgQXV0aG9ycyAgICAgICAg IDogUGF1bCBRdWlubg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBOYWRlYXUN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0 LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTgNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTQt MDQtMTYNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIG92 ZXJ2aWV3IG9mIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiAgICBkZXBsb3ltZW50 IG9mIHNlcnZpY2UgZnVuY3Rpb25zIChzdWNoIGFzIGZpcmV3YWxscywgbG9hZCBiYWxhbmNlcnMp DQo+ICAgIGluIGxhcmdlLXNjYWxlIGVudmlyb25tZW50cy4gIFRoZSB0ZXJtIHNlcnZpY2UgZnVu Y3Rpb24gY2hhaW5pbmcgaXMNCj4gICAgdXNlZCB0byBkZXNjcmliZSB0aGUgZGVmaW5pdGlvbiBh bmQgaW5zdGFudGlhdGlvbiBvZiBhbiBvcmRlcmVkIHNldA0KPiAgICBvZiBpbnN0YW5jZXMgb2Yg c3VjaCBzZXJ2aWNlIGZ1bmN0aW9ucywgYW5kIHRoZSBzdWJzZXF1ZW50ICJzdGVlcmluZyINCj4g ICAgb2YgdHJhZmZpYyBmbG93cyB0aHJvdWdoIHRob3NlIHNlcnZpY2UgZnVuY3Rpb25zLg0KPiAN Cj4gICAgVGhlIHNldCBvZiBlbmFibGVkIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5zIHJlZmxlY3Qg b3BlcmF0b3Igc2VydmljZQ0KPiAgICBvZmZlcmluZ3MgYW5kIGlzIGRlc2lnbmVkIGluIGNvbmp1 bmN0aW9uIHdpdGggYXBwbGljYXRpb24gZGVsaXZlcnkNCj4gICAgYW5kIHNlcnZpY2UgYW5kIG5l dHdvcmsgcG9saWN5Lg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC8NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPiANCj4gQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPiAN Cj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Fri Apr 18 05:42: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 607761A01D4; Fri, 18 Apr 2014 05:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 AsEfLdjiPY4A; Fri, 18 Apr 2014 05:42:45 -0700 (PDT) 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 9A6941A01D9; Fri, 18 Apr 2014 05:42:45 -0700 (PDT) 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.0174.001; Fri, 18 Apr 2014 05:42:41 -0700 From: Ron Parker To: Xuxiaohu , "sfc@ietf.org" Thread-Topic: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWuSwN6yOCWfBXEiCP5lApG8PzpsXUDbQ Date: Fri, 18 Apr 2014 12:42:40 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Uesjn91VOKRev38bWE0GVwNfjnw Cc: "spring@ietf.org" Subject: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-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: Fri, 18 Apr 2014 12:42:47 -0000 WGlhb2h1LA0KDQpXaGlsZSB0aGUgc3RhY2sgb2YgSVAgYWRkcmVzc2VzIGlzIHNpbXBsZSwgY29u Y2VwdHVhbGx5LCBpdCBpcyBxdWl0ZSBleHBlbnNpdmUgb24gdGhlIHdpcmUsIGVzcGVjaWFsbHkg d2l0aCBJUHY2IGFkZHJlc3Nlcy4gICANCg0KQSBzdGFjayBvZiBNUExTIGxhYmVscyBpcyBhbHNv IGNvbmNlcHR1YWxseSBzaW1wbGUsIGJ1dCB0aGUgdXNlIG9mIE1QTFMgaXMgbm90IHVuaXZlcnNh bCwgZXNwZWNpYWxseSB3aXRoaW4gZGF0YSBjZW50ZXIgZW52aXJvbm1lbnRzLiAgIEFsc28sIHRo aXMgdXNlIG9mIHRoZSBNUExTIGxhYmVscyBpcyBzb21ld2hhdCBkaWZmZXJlbnQsIHNlbWFudGlj YWxseSwgYW5kIGNvdWxkIGNhdXNlIGlzc3VlcyBpZiB1c2VkIGNvbmN1cnJlbnRseSB3aXRoIHRy YWRpdGlvbmFsIE1QTFMgdXNlIGNhc2VzLiAgIEVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCBleGlzdGlu ZyBNUExTIGxhYmVscyBhcmUgZG93bnN0cmVhbSBhbGxvY2F0ZWQgYnV0IFNGQyBpcyBlc3NlbnRp YWxseSBzb3VyY2Ugcm91dGVkLiAgIFBlcmhhcHMgdGhhdCBpc3N1ZSBjb3VsZCBiZSBzb2x2ZWQs IGJ1dCBhdCB0aGUgZXhwZW5zZSBvZiBhIG1vcmUgY29tcGxleCBhbmQgaW52YXNpdmUgY29udHJv bCBwbGFuZS4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUN ClNlbnQ6IEZyaWRheSwgQXByaWwgMTgsIDIwMTQgNTowMCBBTQ0KVG86IHNmY0BpZXRmLm9yZw0K Q2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gV2h5IFRyYW5zcG9ydCBEZXBlbmRl bmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1z ZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQoNCkhpIGFsbCwNCg0KSXQgc2FpZCBpbiBzZWN0 aW9uIDIuNi4gIFRyYW5zcG9ydCBEZXBlbmRlbmNlIG9mIHRoZSBQUyBkcmFmdDoNCg0KICAiU2Vy dmljZSBmdW5jdGlvbnMgY2FuIGFuZCB3aWxsIGJlIGRlcGxveWVkIGluIG5ldHdvcmtzIHdpdGgg YSByYW5nZQ0KICAgb2YgdHJhbnNwb3J0cywgaW5jbHVkaW5nIHVuZGVyIGFuZCBvdmVybGF5cy4g IFRoZSBjb3VwbGluZyBvZiBzZXJ2aWNlDQogICBmdW5jdGlvbnMgdG8gdG9wb2xvZ3kgcmVxdWly ZXMgc2VydmljZSBmdW5jdGlvbnMgdG8gc3VwcG9ydCBtYW55DQogICB0cmFuc3BvcnQgZW5jYXBz dWxhdGlvbnMgb3IgZm9yIGEgdHJhbnNwb3J0IGdhdGV3YXkgZnVuY3Rpb24gdG8gYmUNCiAgIHBy ZXNlbnQuIg0KDQpBc3N1bWUgdGhlIGZ1bmN0aW9uIG9mIHNlcnZpY2UgY2hhaW4gY2FuIGJlIGRp dmlkZWQgaW50byB0d28gbGF5ZXJzOiBvbmUgaXMgdGhlIHNlcnZpY2UgcGF0aCBsYXllciB3aGlj aCBpcyByZXNwb25zaWJsZSBmb3Igc3RlZXJpbmcgdGhlIHBhY2tldHMgYWxvbmcgdGhlIHNlcnZp Y2UgcGF0aCwgdGhlIG90aGVyIGlzIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGxheWVyIHdoaWNoIGlz IHJlc3BvbnNpYmxlIGZvciBhcHBseWluZyBhIGdpdmVuIHNlcnZpY2UgdG8gdGhlIHBhY2tldC4g SSBhZ3JlZSB0aGF0IHRyYW5zcG9ydCBkZXBlbmRlbmNlIGlzIGJhZCBmb3IgdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gbGF5ZXIuIEhvd2V2ZXIsIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdHJhbnNwb3J0 IGRlcGVuZGVuY2UgaXMgYWxzbyBiYWQgZm9yIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIuIEluIGZh Y3QsIHRoZXJlIGFyZSBvbmx5IHR3byB1bmRlcmxheSB0cmFuc3BvcnRzIChpLmUuLCBJUCBhbmQg TVBMUykgd2hpY2ggbmVlZCB0byBiZSBjb25zaWRlcmVkIGZvciBzZXJ2aWNlIGNoYWluLiBUaGVy ZWZvcmUsIHdlIGp1c3QgbmVlZCB0byBsZXZlcmFnZSB0aGUgc291cmNlIHJvdXRpbmcgY2FwYWJp bGl0eSBhc3NvY2lhdGVkIHdpdGggSVAgb3IgTVBMUyB0byByZWFsaXplIHRoZSBmdW5jdGlvbiBv ZiB0aGUgc2VydmljZSBwYXRoIGxheWVyLiBUaGF0J3MgdG8gc2F5LCB3ZSBjYW4gdXNlIGFuIG9y ZGVyZWQgbGlzdCBvZiBJUCBhZGRyZXNzZXMgb3IgTVBMUyBsYWJlbHMgY2FycmllZCBpbiB0aGUg cGFja2V0IHRvIHJlcHJlc2VudCB0aGUgc2VydmljZSBwYXRoLiBBIE1QTFMgbGFiZWwgaW4gdGhl IG9yZGVyZWQgbGlzdCBvZiBNUExTIGxhYmVscyAoaS5lLiwgYSBNUExTIGxhYmVsIHN0YWNrKSBv ciBhbiBJUCBhZGRyZXNzIGluIHRoZSBvcmRlcmVkIGxpc3Qgb2YgSVAgYWRkcmVzc2VzIGNhbiBi ZSB1c2VkIHRvIGluZGljYXRlIGVpdGhlciBhIHNlcnZpY2Ugbm9kZSB3aXRoaW4gdGhlIHNlcnZp Y2UgcGF0aCBvciBhIHNlcnZpY2UgZnVuY3Rpb24gb24gYSBnaXZlbiBzZXJ2aWNlIG5vZGUuIE5v dGUgdGhhdCBNUExTIGxhYmVscyBhbmQgSVAgYWRkcmVzc2VzIGhhdmUgYmVlbiBzdWNjZXNzZnVs bHkgdXNlZCBmb3IgaW5kaWNhdGluZyBzZXJ2aWNlcyAoZS5nLiwgVlBOIGxhYmVscyBhbmQgbXVs dGljYXN0IGFkZHJlc3NlcyBpbiB0aGUgcmFuZ2Ugb2YgMjI0LjAuMC54IG9yIEZGMDI6OnggKS4g DQoNCk9mIGNvdXJzZSwgaWYgeW91IHN0aWxsIHRoaW5rIHRoZXJlIGFyZSB0b28gbXVjaCB3b3Jr IHRvIGRvLCB5b3UgY291bGQgYWN0dWFsbHkgb25seSBjb25zaWRlciB0aGUgTVBMUy1iYXNlZCBh cHByb2FjaCAoaS5lLiwgdXNpbmcgYSBNUExTIGxhYmVsIHN0YWNrIHRvIHJlcHJlc2VudCBhIHNl cnZpY2UgcGF0aCkgc2luY2UgaXQgY291bGQgYWxzbyBiZSBhcHBsaWNhYmxlIGluIGJvdGggSVB2 NCBhbmQgSVB2NiBuZXR3b3JrcyB3aXRoIHRoZSBoZWxwIG9mIGFueSBraW5kIG9mIE1QTFMgb3Zl ciBJUCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ2llcy4gDQoNCkJlc3QgcmVnYXJkcywNClhpYW9o dQ0KDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ILeiy83Ksbzk OiAyMDE0xOo01MIxN8jVIDM6MTgNCj4gytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4g s63LzTogc2ZjQGlldGYub3JnDQo+INb3zOI6IFtzZmNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt c2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NCj4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlcnZpY2UgRnVuY3Rp b24gQ2hhaW5pbmcgV29ya2luZyANCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAg IFRpdGxlICAgICAgICAgICA6IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgUHJvYmxlbSBTdGF0 ZW1lbnQNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBQYXVsIFF1aW5uDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhvbWFzIE5hZGVhdQ0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+IAlQYWdlcyAgICAgICAgICAg OiAxOA0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNC0wNC0xNg0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIGlzc3VlcyBhc3Nv Y2lhdGVkIHdpdGggdGhlDQo+ICAgIGRlcGxveW1lbnQgb2Ygc2VydmljZSBmdW5jdGlvbnMgKHN1 Y2ggYXMgZmlyZXdhbGxzLCBsb2FkIGJhbGFuY2VycykNCj4gICAgaW4gbGFyZ2Utc2NhbGUgZW52 aXJvbm1lbnRzLiAgVGhlIHRlcm0gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcw0KPiAgICB1 c2VkIHRvIGRlc2NyaWJlIHRoZSBkZWZpbml0aW9uIGFuZCBpbnN0YW50aWF0aW9uIG9mIGFuIG9y ZGVyZWQgc2V0DQo+ICAgIG9mIGluc3RhbmNlcyBvZiBzdWNoIHNlcnZpY2UgZnVuY3Rpb25zLCBh bmQgdGhlIHN1YnNlcXVlbnQgInN0ZWVyaW5nIg0KPiAgICBvZiB0cmFmZmljIGZsb3dzIHRocm91 Z2ggdGhvc2Ugc2VydmljZSBmdW5jdGlvbnMuDQo+IA0KPiAgICBUaGUgc2V0IG9mIGVuYWJsZWQg c2VydmljZSBmdW5jdGlvbiBjaGFpbnMgcmVmbGVjdCBvcGVyYXRvciBzZXJ2aWNlDQo+ICAgIG9m ZmVyaW5ncyBhbmQgaXMgZGVzaWduZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhcHBsaWNhdGlvbiBk ZWxpdmVyeQ0KPiAgICBhbmQgc2VydmljZSBhbmQgbmV0d29yayBwb2xpY3kuDQo+IA0KPiANCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3Rh dGVtZW50Lw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0t c3RhdGVtZW50LTA0DQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Fri Apr 18 15:08: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 947EA1A02F2 for ; Fri, 18 Apr 2014 15:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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.272, 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 nbgcFJCQkuq3 for ; Fri, 18 Apr 2014 15:08:37 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD611A01F0 for ; Fri, 18 Apr 2014 15:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5594; q=dns/txt; s=iport; t=1397858913; x=1399068513; h=from:to:subject:date:message-id:mime-version; bh=NgOEl8E9e8TORh08rqrptVCZ9VX08pOHc2r/TY5Csg8=; b=AazA1W+/ikG5gaUOQxuF4uV/ipMdpe5i1QEdzpYqvqC42vNyqhdj2U38 eky1+Yz7Lcv603rxBSK58w90tU87Tbj5GGdj9k6OwqrBMNEzQBInVZd1f tgJErhJN8dTEjkahR0zGZY0wq2XgJVbEwOULX3TpKWiBmvj3MP0ZeiwHR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANmhUVOtJV2c/2dsb2JhbABQCoJCRIEmxRcWdIIsHU4gAQx0JwSIVJpisjYXjgaFGwSYbpJPgzGCKw X-IronPort-AV: E=Sophos; i="4.97,886,1389744000"; d="scan'208,217"; a="37016316" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 18 Apr 2014 22:08:33 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3IM8Xsw005372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Apr 2014 22:08:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 17:08:33 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Progression of SFC use case documents Thread-Index: AQHPW1K8K2mTLR48uE+GohTdExdCcw== Date: Fri, 18 Apr 2014 22:08:32 +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.180] Content-Type: multipart/alternative; boundary="_000_CF771A9C1F815jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lHTA7NPx0pOojI590OL6khPu0Qo Subject: [sfc] Progression of SFC use case documents 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, 18 Apr 2014 22:08:39 -0000 --_000_CF771A9C1F815jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG: There has been much discussion both on the list and during our face-to-face= meetings about how best to progress use case documents within the WG. Ther= e are clearly arguments for both of the following approaches: 1. A single document that captures all of the possible use cases. 2. A small number of targeted documents that are focused on a particular= subset of the overall problem space (such as broadband, mobility, and data= center). But, we can=92t choose both. In considering these approaches, the chairs re= cognize that there are benefits to having a single document, but do not bel= ieve having just one document is workable in this case. Nor is there consen= sus for having a single document. Therefore, we will pursue the following = approach going forward: 1. Adopt a small number of WG documents (initially 2) that are applicabl= e to specific environments and that can be worked on independently by membe= rs of the WG that have the necessary expertise for that environment, and th= at can work directly with the applicable SDOs on incorporating relevant con= tent. 2. Continue to leave open the possibility of adopting a high-level use c= ase document that serves as a =93catch all=94 for use cases that do not mer= it their own document or are not captured in the content of more focused us= e case documents. However, before taking on such a document, the WG will ne= ed to understand in more detail what the content would be and that the cont= ent justifies having such a document. Such a document should not duplicate = material that is covered in other documents. To facilitate the above direction the chairs will take the following steps: 1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and draf= t-kumar-sfc-dc-use-cases as WG documents. 2. Encourage the authors to continue to work on refinement of draft-liu-= sfc-use-cases. The authors of that document should update their draft to re= move any duplication of material covered in other documents as well as iden= tify content that is not covered elsewhere. We hope that this approach will allow the WG to move forward and also provi= de enough flexibility to allow use cases to evolve independently, with dire= ct interaction with the appropriate SDOs. Thanks, Jim & Thomas --_000_CF771A9C1F815jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <016BF80E3F34B24C830419237321FBCF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Dear WG:

There has been much discussion both on the list and during our face-to= -face meetings about how best to progress use case documents within the WG.= There are clearly arguments for both of the following approaches:
  1. A single document that captures all of the possible use cases.
  2. = A small number of targeted documents that are focused on a particular subse= t of the overall problem space (such as broadband, mobility, and data cente= r).
But, we can=92t choose both. In considering these approaches, the chai= rs recognize that there are benefits to having a single document, but do no= t believe having just one document is workable in this case. Nor is there c= onsensus for having a single document.  Therefore, we will pursue the following approach going forward:
  1. Adopt a small number of WG documents (initially 2) that are applicable = to specific environments and that can be worked on independently by members= of the WG that have the necessary expertise for that environment, and that= can work directly with the applicable SDOs on incorporating relevant content.
  2. Continue to leave open the= possibility of adopting a high-level use case document that serves as a = =93catch all=94 for use cases that do not merit their own document or are n= ot captured in the content of more focused use case documents. However, bef= ore taking on such a document, the WG will need to understand in more detail what the= content would be and that the content justifies having such a document. Su= ch a document should not duplicate material that is covered in other docume= nts. 
To facilitate the above direction the chairs will take the following s= teps:
  1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and draft-= kumar-sfc-dc-use-cases as WG documents.
  2. Encourage the authors to co= ntinue to work on refinement of draft-liu-sfc-use-cases. The authors of tha= t document should update their draft to remove any duplication of material = covered in other documents as well as identify content that is not covered = elsewhere. 
We hope that this approach will allow the WG to move forward and also = provide enough flexibility to allow use cases to evolve independently, with= direct interaction with the appropriate SDOs.

Thanks,

Jim & Thomas
--_000_CF771A9C1F815jguicharciscocom_-- From nobody Fri Apr 18 15:30: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 E91651A014D for ; Fri, 18 Apr 2014 15:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 I5FkxgWugonI for ; Fri, 18 Apr 2014 15:30:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD9A1A01B5 for ; Fri, 18 Apr 2014 15:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2614; q=dns/txt; s=iport; t=1397860197; x=1399069797; h=from:to:subject:date:message-id:mime-version; bh=ZXIggB2nXsU+8YTXW5UIAfmVApHQVKX4daalJc+ChuI=; b=TUOf2lNg+Ys8EeQEG4PAvcdG6qgzhLEGiqJzEx8KGmKwG6qWRUjmhoeh DF7d8P8NbTUjKpMlGg/C9SYrXhKnBCIAhnfYiVvT/QgC7HhiUSXVPCsov 2nhobn2Hjsv0OHzgeSGR3e13nY6HPv5F2r9X0YNNCqDJ5Z68wWHgCrQ/3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAMOmUVOtJV2Y/2dsb2JhbABagkJET1fFFxZ0giwdUR0BDAFzJwQciDgNmlOyNxeTIQSYbpJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208,217";a="318827205" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 18 Apr 2014 22:29:57 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IMTv16020250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Apr 2014 22:29:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 17:29:56 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVg== Date: Fri, 18 Apr 2014 22:29:57 +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.180] Content-Type: multipart/alternative; boundary="_000_CF771F9E1F82Cjguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/aDsfxckCiKSQsF5Sz0SPfX-Mu4g Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 18 Apr 2014 22:30:08 -0000 --_000_CF771F9E1F82Cjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF771F9E1F82Cjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8008E8A7C6099D4E964C6594F23610FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
--_000_CF771F9E1F82Cjguicharciscocom_-- From nobody Fri Apr 18 15:31: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 5F1711A01F0 for ; Fri, 18 Apr 2014 15:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 UYqHYqCXISHR for ; Fri, 18 Apr 2014 15:31:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB81A01B5 for ; Fri, 18 Apr 2014 15:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2602; q=dns/txt; s=iport; t=1397860309; x=1399069909; h=from:to:subject:date:message-id:mime-version; bh=eUiTi/T4oOog4x2DCDy9WR0lJ3m1oCKzkmiRcgZ70h8=; b=JzmkQBF72uMDDiJlRjjmR30BAEFxXdKA4Gq+lSDJFN42sQukp59DQy77 tYP9MXENbt7MLhHB76y5xVpKT3Nyklng/6PZxZqLpsip1c2sxjYNIIXF3 lAIYYIIXz17e2GYiCZNPiw6hrq+X0tSgZhZb/M9/riFHbsbMU/Vf3GHRC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAPumUVOtJV2a/2dsb2JhbABagkJET1fFFxZ0giwdUR0BDAFzJwQciDgNmlOyNxeTIQSYbpJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208,217";a="318835094" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 18 Apr 2014 22:31:48 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3IMVmsN025610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Apr 2014 22:31:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 17:31:48 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkQ== Date: Fri, 18 Apr 2014 22:31:48 +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.180] Content-Type: multipart/alternative; boundary="_000_CF77200F1F832jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7z5sr9ejiRPLZHu5siheMuen1oA Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 18 Apr 2014 22:31:54 -0000 --_000_CF77200F1F832jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF77200F1F832jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear WG:

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
--_000_CF77200F1F832jguicharciscocom_-- From nobody Fri Apr 18 16:06: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 0092F1A03E2 for ; Fri, 18 Apr 2014 16:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 wvSh0Kulq0cf for ; Fri, 18 Apr 2014 16:06:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBC21A03BE for ; Fri, 18 Apr 2014 16:06:03 -0700 (PDT) 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 BFV31087; Fri, 18 Apr 2014 23:05:58 +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; Sat, 19 Apr 2014 00:04:15 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Apr 2014 00:05:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Fri, 18 Apr 2014 16:05:45 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of SFC use case documents Thread-Index: AQHPW1K8K2mTLR48uE+GohTdExdCc5sX9Odg Date: Fri, 18 Apr 2014 23:05:44 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@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.47.136.35] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45371EBEdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cmyRZ2zvwppOs5K2GNBvdKj6OMU Subject: Re: [sfc] Progression of SFC use case documents 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, 18 Apr 2014 23:06:08 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45371EBEdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Chairs, People including myself did not voice a single document to capture all poss= ible use cases because there is no need to do that. We suggested capturing = all necessary use cases that help driving the architecture and requirement = development. Giving the situation, I support adopting draft-haeffner-sfc-use-case-moblit= y as WG draft. This is because a large portion of SFC use cases are in Mobi= le applications; and the draft describes many unique ways to use SFC. It is= good to have one draft to cover Mobile area. IMO: draft-kumar-sfc-dc-use-cases does not depict unique SFC cases from a g= eneral SFC case except the SFC applications location is in data centers. Th= us these cases can be easily merged into the general use case draft. So we = have another use case draft for the rest. Regards, Lucy Dear WG: There has been much discussion both on the list and during our face-to-face= meetings about how best to progress use case documents within the WG. Ther= e are clearly arguments for both of the following approaches: 1. A single document that captures all of the possible use cases. 2. A small number of targeted documents that are focused on a particular= subset of the overall problem space (such as broadband, mobility, and data= center). But, we can't choose both. In considering these approaches, the chairs reco= gnize that there are benefits to having a single document, but do not belie= ve having just one document is workable in this case. Nor is there consensu= s for having a single document. Therefore, we will pursue the following ap= proach going forward: 1. Adopt a small number of WG documents (initially 2) that are applicabl= e to specific environments and that can be worked on independently by membe= rs of the WG that have the necessary expertise for that environment, and th= at can work directly with the applicable SDOs on incorporating relevant con= tent. 2. Continue to leave open the possibility of adopting a high-level use c= ase document that serves as a "catch all" for use cases that do not merit t= heir own document or are not captured in the content of more focused use ca= se documents. However, before taking on such a document, the WG will need t= o understand in more detail what the content would be and that the content = justifies having such a document. Such a document should not duplicate mate= rial that is covered in other documents. To facilitate the above direction the chairs will take the following steps: 1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and draf= t-kumar-sfc-dc-use-cases as WG documents. 2. Encourage the authors to continue to work on refinement of draft-liu-= sfc-use-cases. The authors of that document should update their draft to re= move any duplication of material covered in other documents as well as iden= tify content that is not covered elsewhere. We hope that this approach will allow the WG to move forward and also provi= de enough flexibility to allow use cases to evolve independently, with dire= ct interaction with the appropriate SDOs. Thanks, Jim & Thomas --_000_2691CE0099834E4A9C5044EEC662BB9D45371EBEdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Chairs,

 <= /p>

People including my= self did not voice a single document to capture all possible use cases beca= use there is no need to do that. We suggested capturing all necessary use cases that help driving the architecture and requirement= development.

 

Giving the situatio= n, I support adopting draft-haeffner-sfc-use-case-moblity as WG draft. This= is because a large portion of SFC use cases are in Mobile applications; and the draft describes many unique ways to use SFC. It is g= ood to have one draft to cover Mobile area.

 

IMO: draft-kumar-sf= c-dc-use-cases does not depict unique SFC cases from a general SFC case exc= ept the SFC applications location is in data centers. Thus these cases can be easily merged into the general use case draft. So we ha= ve another use case draft for the rest.

 

Regards,=

Lucy=

 

Dear WG:<= /p>

 

There has been much discuss= ion both on the list and during our face-to-face meetings about how best to= progress use case documents within the WG. There are clearly arguments for both of the following approaches:

  1. A single document that captures all of the possible use cases.=
  2. A small number of targeted documents that are focused on a par= ticular subset of the overall problem space (such as broadband, mobility, a= nd data center).

But, we can’t choose = both. In considering these approaches, the chairs recognize that there are = benefits to having a single document, but do not believe having just one document is workable in this case. Nor is there consensus for hav= ing a single document.  Therefore, we will pursue the following approa= ch going forward:

  1. Adopt a small number of WG documents (initially 2) that are ap= plicable to specific environments and that can be worked on independently b= y members of the WG that have the necessary expertise for that environment, and that can work directly with the applicable SDOs = on incorporating relevant content.
  2. Continue to leave open the possibility of adopting a high-leve= l use case document that serves as a “catch all” for use cases = that do not merit their own document or are not captured in the content of more focused use case documents. However, before taking on such a docum= ent, the WG will need to understand in more detail what the content would b= e and that the content justifies having such a document. Such a document sh= ould not duplicate material that is covered in other documents. 

To facilitate the above dir= ection the chairs will take the following steps:

  1. Call for the adoption of draft-haeffner-sfc-use-case-moblity a= nd draft-kumar-sfc-dc-use-cases as WG documents.
  2. Encourage the authors to continue to work on refinement of dra= ft-liu-sfc-use-cases. The authors of that document should update their draf= t to remove any duplication of material covered in other documents as well as identify content that is not covered elsewhere. =

We hope that this approach = will allow the WG to move forward and also provide enough flexibility to al= low use cases to evolve independently, with direct interaction with the appropriate SDOs.

 

Thanks,

 

Jim & Thomas=

--_000_2691CE0099834E4A9C5044EEC662BB9D45371EBEdfweml701chmchi_-- From nobody Fri Apr 18 16:25:18 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 9A8F51A0503 for ; Fri, 18 Apr 2014 16:25:13 -0700 (PDT) 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 CArvz8jY477W for ; Fri, 18 Apr 2014 16:25:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id C6E521A04F6 for ; Fri, 18 Apr 2014 16:25:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0EADF52101F; Fri, 18 Apr 2014 16:25:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7068F52104B; Fri, 18 Apr 2014 16:25:07 -0700 (PDT) Message-ID: <5351B452.6010400@joelhalpern.com> Date: Fri, 18 Apr 2014 19:25:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yLw87p0Od787J7g1uVTpacxjm6Y Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 18 Apr 2014 23:25:13 -0000 I support adoption of this document by the working group. It is a good starting point for addressing the material it covers, and the working group should cover that material. Yours, Joel On 4/18/14, 6:29 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd > May 2014. > > Please respond to the SFC mailing list with any statements of approval > or disapproval. > > 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. Therefore, 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 them. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Apr 18 16:25: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 C97A21A0503 for ; Fri, 18 Apr 2014 16:25:27 -0700 (PDT) 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 T0yDf88NcosO for ; Fri, 18 Apr 2014 16:25:26 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0E51A04F6 for ; Fri, 18 Apr 2014 16:25:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7A921521052; Fri, 18 Apr 2014 16:25:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CD37C521017; Fri, 18 Apr 2014 16:25:21 -0700 (PDT) Message-ID: <5351B460.5040709@joelhalpern.com> Date: Fri, 18 Apr 2014 19:25:20 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BjbW9hlI5BBlZsUaAKpnmzUhw-U Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 18 Apr 2014 23:25:27 -0000 I support adoption of this document by the working group. It is a good starting point for addressing the material it covers, and the working group should cover that material. Yours, Joel On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd > May 2014. > > Please respond to the SFC mailing list with any statements of approval > or disapproval. > > 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. Therefore, 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 them. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat Apr 19 07:13: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 2FBE81A0249 for ; Sat, 19 Apr 2014 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 BbR8UbuYsQHi for ; Sat, 19 Apr 2014 07:13:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 28A2C1A0241 for ; Sat, 19 Apr 2014 07:13:14 -0700 (PDT) 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 BDG90944; Sat, 19 Apr 2014 14:13:09 +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; Sat, 19 Apr 2014 15:12:24 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Apr 2014 15:13:08 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Sat, 19 Apr 2014 07:12:56 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsY/TGA Date: Sat, 19 Apr 2014 14:12:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45371F83@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.47.135.112] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45371F83dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dWYdrEtppZobSig3sKCUKKFDlWY Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 19 Apr 2014 14:13:23 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45371F83dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! Cheers, Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 5:30 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_2691CE0099834E4A9C5044EEC662BB9D45371F83dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support!

 <= /p>

Cheers,=

Lucy

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 5:30 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/dr= aft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_2691CE0099834E4A9C5044EEC662BB9D45371F83dfweml701chmchi_-- From nobody Sat Apr 19 07: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 E8DC91A0004 for ; Sat, 19 Apr 2014 07:36:22 -0700 (PDT) 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, 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 E4awTKH4FskB for ; Sat, 19 Apr 2014 07:36:21 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CDF1A0002 for ; Sat, 19 Apr 2014 07:36:20 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3JEUEpg023075; Sat, 19 Apr 2014 07:36:13 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1k9uusa53c-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Apr 2014 07:36:13 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 19 Apr 2014 07:36:12 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Sat, 19 Apr 2014 07:36:12 -0700 From: ramki Krishnan To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Sat, 19 Apr 2014 07:36:09 -0700 Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsZAqLg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C004004217HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-18_01:2014-04-18,2014-04-18,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-1402240000 definitions=main-1404190257 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dGCi2lH01H8kk6ra8CiXuG6NkdY Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 19 Apr 2014 14:36:23 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C004004217HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 3:30 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is exp= ected to modify the document's content until there is WG consensus that the= content is solid. Therefore, 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 a= nd we can begin a dialog about how best to address them. --_000_C7634EB63EFD984A978DFB46EA5174F2C004004217HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.<= o:p>

 

Thanks,

Ramki

&nb= sp;

From: sfc [mailto:sfc-= bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 3:30 PM
To: sfc@ietf.org
Subject:= [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

 

Dear WG:

 

This message begins a two week call for WG adoption of the docume= nt http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.= txt ending 2nd May 2014. 

 

Please respond to the SFC mailing list with any statements of = approval or disapproval.

 

Pl= ease 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. Therefore, please don’t op= pose adoption just because you want to see changes to its content.
  2. If you have objections t= o 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 them= . 
= --_000_C7634EB63EFD984A978DFB46EA5174F2C004004217HQ1EXCH01corp_-- From nobody Sat Apr 19 09:55: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 F11561A0040 for ; Sat, 19 Apr 2014 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 rrXDIohOooB6 for ; Sat, 19 Apr 2014 09:54:54 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2571A0032 for ; Sat, 19 Apr 2014 09:54:53 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N4A00J81EZC8O@tid.hi.inet> for sfc@ietf.org; Sat, 19 Apr 2014 18:54:48 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 7D.BE.03633.235C2535; Sat, 19 Apr 2014 20:49:23 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N4A00J7XEZB8O@tid.hi.inet> for sfc@ietf.org; Sat, 19 Apr 2014 18:54:47 +0200 (MEST) Received: from EX10-MB1-BCN.hi.inet ([169.254.4.22]) by EX10-HTCAS2-BCN.hi.inet ([fe80::a3:312:1b4e:7674%11]) with mapi id 14.03.0158.001; Sat, 19 Apr 2014 18:54:47 +0200 Date: Sat, 19 Apr 2014 16:54:45 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.100.1] To: "Jim Guichard (jguichar)" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NeJVYD1j+gOLPUl85uXEJw)" Content-language: en-US Accept-Language: en-US Thread-topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsZB/IA X-AuditID: 0a5f4e69-f794e6d000000e31-79-5352c53208aa X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsXCFe9nqGt8NCjYYIuLxZMHW9kdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXx5vMWtoK/uhX3Jh5ia2B8ot7FyMkhIWAiseJUDzOELSZx4d56 ti5GLg4hge2MEku/3meCcL4zSlx9v5QVpEpIYB2jxNPLASA2i4CqxNQpPSwgNhuQ/aj5N3sX IweHsIC/xKLmJJAwp4CBxN6TZ9lAwhIC8hI376qChEUEjCS6L70Hm8gsoCgx4d1bdhCbV8BS 4vqWPawQtqDEj8n3WCBqoiUaXz1kgrDFJZpbb4LFGYFu/n5qDRPEzACJ35d3ssLM37Z+F9Rf AhJL9pyHskUlXj7+B/WJvsSyC8vZJzCKzUKybhaSdbOQrIOwDSTen5vPDGFrSyxb+BrK1pfY +OUsI4RtJnH7cTMbspoFjByrGMWKk4oy0zNKchMzc9INjPQyMvUy81JLNjFCIjFzB+PynSqH GAU4GJV4eC/kBAYLsSaWFVfmHmKU4GBWEuHdNTsoWIg3JbGyKrUoP76oNCe1+BCjNAeLkjgv 87uiACGB9MSS1OzU1ILUIpgsEwenVAPjDn8NCeP6w3nF3Jdl1pbdCYhYcFlww9/s918PK+i9 zLqx5Yj9OXWtm98OhFu5bl05Ydvrcxx9Yhedyjd5njpyz/Ra3ZzEP0f9vzTwnzh8YvOcJQE/ eWar7fJ5V17Sd/hJjbFD763e3bc4O2I5/0bcndbJeaLozv9DgbH2Tsnut/5V7smMtJT0VGIp zkg01GIuKk4EAIFBOb/AAgAA References: Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qr49FXFYQf8ioqw3EzuuewjNewI Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 19 Apr 2014 16:54:59 -0000 --Boundary_(ID_NeJVYD1j+gOLPUl85uXEJw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Support. On 19 Apr 2014, at 00:29 , Jim Guichard (jguichar) > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_NeJVYD1j+gOLPUl85uXEJw) Content-id: <005D4FACDF73D746A4DD3A7511A8E350@hi.inet> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable Support.

On 19 Apr 2014, at 00:29 , Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_NeJVYD1j+gOLPUl85uXEJw)-- From nobody Sat Apr 19 10:12: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 7346C1A0055 for ; Sat, 19 Apr 2014 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 f4gEbtijgzPH for ; Sat, 19 Apr 2014 10:12:40 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id BDE251A005F for ; Sat, 19 Apr 2014 10:12:35 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N4A00JXMFSS8O@tid.hi.inet> for sfc@ietf.org; Sat, 19 Apr 2014 19:12:29 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id FB.CE.03633.759C2535; Sat, 19 Apr 2014 21:07:03 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N4A00JXHFSS8O@tid.hi.inet> for sfc@ietf.org; Sat, 19 Apr 2014 19:12:28 +0200 (MEST) Received: from EX10-MB1-BCN.hi.inet ([169.254.4.22]) by EX10-HTCAS3-BCN.hi.inet ([fe80::e55b:4382:96ce:7c50%13]) with mapi id 14.03.0158.001; Sat, 19 Apr 2014 19:12:27 +0200 Date: Sat, 19 Apr 2014 17:12:26 +0000 From: "Diego R. Lopez" In-reply-to: <5351B460.5040709@joelhalpern.com> X-Originating-IP: [10.95.100.1] To: "Joel M. Halpern" Message-id: <7AC6A5ED-AD8D-4F4A-9605-E11316B5E41A@tid.es> Content-id: <1CBDE8D451DECC4EA16332F6A0553ABE@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsX4roAgAEqJwA= X-AuditID: 0a5f4e69-f794e6d000000e31-e9-5352c95746b1 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsXCFe9nqBt+MijYoOmonsWTB1vZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWqBYkGDYEX/0+QGxlu8XYzsHBICJhJTirsYOYEsMYkL99az dTFycQgJbGeU2LVmAwuE851R4lHbXxaQKiGBjYwSn2exgdgsAqoSZ1bMZgax2YDsR82/2UFs YQF3ic6Gp2A1nAL6Etv3rQXq5QDaIC9x864qSFhEQFti/5IPTCA2s0CwxP9VHYwgNq+ApcT+ 5Reh4mYS0058YIOIC0r8mHyPBSKuJ/Hxz21GCFtcorn1JlRcW+LJuwusIDajgKzEu/nzWSF2 eUjcb1nDAmFbSTxb+5cR4mEBiSV7zjND2KISLx//Y4V4MUTi0s9HLBMYJWYhOWMWkjNmITlj FpIzZiE5YwEj6ypGseKkosz0jJLcxMycdAMjvYxMvcy81JJNjJBoy9zBuHynyiFGAQ5GJR7e CzmBwUKsiWXFlbmHGCU4mJVEeHfNDgoW4k1JrKxKLcqPLyrNSS0+xCjNwaIkzsv8rihASCA9 sSQ1OzW1ILUIJsvEwSnVwMiq3Oz0unoW76O3xwSVJINvqoRV8QpeuZ/m/Cy+Rmce07bei+0W S+p5NLYYZRk3BreXmLz47H3H+JM3/1unA75lr5+xGu9vq0+afFdjeubEMJWEtUFP3Wxswg98 fxJ71HUKW8yb7jKGG+Fz+n/tOrUu1bP+SffPBp3lNYusqlP4WWTXSK7oVmIpzkg01GIuKk4E AHhNZrSyAgAA References: <5351B460.5040709@joelhalpern.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HrCp3H1mEHDSUeL3FdEyCKt1qB8 Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 19 Apr 2014 17:12:48 -0000 I support as well On 19 Apr 2014, at 01:25 , Joel M. Halpern wrote: > I support adoption of this document by the working group. It is a good s= tarting point for addressing the material it covers, and the working group = should cover that material. > > Yours, > Joel > > On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: >> Dear WG: >> >> This message begins a two week call for WG adoption of the document >> http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd >> May 2014. >> >> Please respond to the SFC mailing list with any statements of approval >> or disapproval. >> >> Please note: >> >> 1. This is not WG Last Call. The document is not final, and the WG is >> expected to modify the document=92s content until there is WG >> consensus that the content is solid. Therefore, please don=92t 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 them. >> >> >> >> _______________________________________________ >> 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From nobody Sun Apr 20 16:13: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 CBB6E1A007D for ; Sun, 20 Apr 2014 16:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 rIYq1uWcV50A for ; Sun, 20 Apr 2014 16:13:52 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 71CDE1A0072 for ; Sun, 20 Apr 2014 16:13:52 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,894,1389772800"; d="scan'208,217"; a="25782622" Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw1-out.broadcom.com with ESMTP; 20 Apr 2014 17:19:38 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 20 Apr 2014 16:13:47 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Sun, 20 Apr 2014 16:13:47 -0700 From: Rajeev Manur To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsbJZtA Date: Sun, 20 Apr 2014 23:13:47 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED31D4107B@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_1E714095C88C9D408749A723A59CF6ED31D4107BSJEXCHMB12corpa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0QffHvLfwXi-5DJSD5cXPvk1Sgo Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 20 Apr 2014 23:13:55 -0000 --_000_1E714095C88C9D408749A723A59CF6ED31D4107BSJEXCHMB12corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 3:30 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_1E714095C88C9D408749A723A59CF6ED31D4107BSJEXCHMB12corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 3:30 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/dr= aft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_1E714095C88C9D408749A723A59CF6ED31D4107BSJEXCHMB12corpa_-- From nobody Sun Apr 20 16:14: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 82AE11A007D for ; Sun, 20 Apr 2014 16:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 nARlzVIKHQrk for ; Sun, 20 Apr 2014 16:14:36 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id F3FAB1A0072 for ; Sun, 20 Apr 2014 16:14:35 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,894,1389772800"; d="scan'208,217"; a="25782628" Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw1-out.broadcom.com with ESMTP; 20 Apr 2014 17:20:22 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 20 Apr 2014 16:14:31 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Sun, 20 Apr 2014 16:14:31 -0700 From: Rajeev Manur To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsbJciQ Date: Sun, 20 Apr 2014 23:14:30 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED31D410B1@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_1E714095C88C9D408749A723A59CF6ED31D410B1SJEXCHMB12corpa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NPipHy2bG5G0FRvvV-WlXKNTjug Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 20 Apr 2014 23:14:39 -0000 --_000_1E714095C88C9D408749A723A59CF6ED31D410B1SJEXCHMB12corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 3:32 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_1E714095C88C9D408749A723A59CF6ED31D410B1SJEXCHMB12corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support=

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 3:32 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/draft-kuma= r-sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_1E714095C88C9D408749A723A59CF6ED31D410B1SJEXCHMB12corpa_-- From nobody Sun Apr 20 16:19: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 6315A1A007D for ; Sun, 20 Apr 2014 16:19:22 -0700 (PDT) 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 aP71g20LA_er for ; Sun, 20 Apr 2014 16:19:18 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1148F1A0072 for ; Sun, 20 Apr 2014 16:19:18 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3KNAwkj001380; Sun, 20 Apr 2014 16:19:11 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1kcfjk84ua-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 20 Apr 2014 16:19:11 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 20 Apr 2014 16:19:10 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Sun, 20 Apr 2014 16:19:10 -0700 From: ramki Krishnan To: "Diego R. Lopez" , "Joel M. Halpern" Date: Sun, 20 Apr 2014 16:19:12 -0700 Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsX4roAgAEqJwCAAhpCEA== Message-ID: References: <5351B460.5040709@joelhalpern.com> <7AC6A5ED-AD8D-4F4A-9605-E11316B5E41A@tid.es> In-Reply-To: <7AC6A5ED-AD8D-4F4A-9605-E11316B5E41A@tid.es> 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.96, 1.0.14, 0.0.0000 definitions=2014-04-20_02:2014-04-18,2014-04-20,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-1402240000 definitions=main-1404200405 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rxfJ9lxIYflepz4EuZn3VDYf1ko Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 20 Apr 2014 23:19:22 -0000 Support. Thanks, Ramki -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Diego R. Lopez Sent: Saturday, April 19, 2014 10:12 AM To: Joel M. Halpern Cc: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 I support as well On 19 Apr 2014, at 01:25 , Joel M. Halpern wrote: > I support adoption of this document by the working group. It is a good s= tarting point for addressing the material it covers, and the working group = should cover that material. > > Yours, > Joel > > On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: >> Dear WG: >> >> This message begins a two week call for WG adoption of the document=20 >> http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd=20 >> May 2014. >> >> Please respond to the SFC mailing list with any statements of=20 >> approval or disapproval. >> >> 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. Therefore, 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 them. >> >> >> >> _______________________________________________ >> 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Apr 20 16:52: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 0FC501A0089 for ; Sun, 20 Apr 2014 16:52:47 -0700 (PDT) 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 BrLPhxJT5Usj for ; Sun, 20 Apr 2014 16:52:42 -0700 (PDT) Received: from smtp89.ord1c.emailsrvr.com (smtp89.ord1c.emailsrvr.com [108.166.43.89]) by ietfa.amsl.com (Postfix) with ESMTP id BD47A1A0076 for ; Sun, 20 Apr 2014 16:52:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id EAD7E14069A; Sun, 20 Apr 2014 19:52:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 54043140237; Sun, 20 Apr 2014 19:52:35 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3FD7AFBE-E4B9-4162-9FAD-2781A0E01DFE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Barry Greene In-Reply-To: Date: Mon, 21 Apr 2014 06:52:31 +0700 Message-Id: <61F6D444-0786-4875-BC2B-833F0AED0BA4@senki.org> References: To: Jim Guichard X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/c-E4xT5kO1dU4JbkFVHAcjZgCRY Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 20 Apr 2014 23:52:47 -0000 --Apple-Mail=_3FD7AFBE-E4B9-4162-9FAD-2781A0E01DFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I support, but it could be better if 1.2 had a simple reference to "new = service." It would fit with the rest of the document.=20 On Apr 19, 2014, at 5:29 AM, Jim Guichard (jguichar) = wrote: > Dear WG: >=20 > This message begins a two week call for WG adoption of the document = http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt = ending 2nd May 2014.=20 >=20 > Please respond to the SFC mailing list with any statements of approval = or disapproval. >=20 > Please note: > =95 This is not WG Last Call. The document is not final, and the = WG is expected to modify the document=92s content until there is WG = consensus that the content is solid. Therefore, please don=92t oppose = adoption just because you want to see changes to its content. > =95 If you have objections to adoption of the document, please = state your reasons why, and explain what it would take to address your = concerns. > =95 If you have issues with the content, by all means raise = those issues and we can begin a dialog about how best to address them.=20= > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_3FD7AFBE-E4B9-4162-9FAD-2781A0E01DFE 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 iQEcBAEBCgAGBQJTVF2/AAoJEFVuk3AWv0XzXagH/Ay6uO4WcC1488z8DED0icsZ Wz0dmH8JN0wrPZe8lwmP6q0Wv72IUiqeIkWbDGv8zA7F65GYOBDNJfgiopRny0eQ bEoA6io5MxB65RGNsMqfcn9x7Ll8wiNTsjH31mLslB2lcJ8gDLprmm76YVGG1AHI fRLzWRukP0tGf4dVSMqY7VWXOkq3Pxx9sjlqDBmcLDNfT7+kdUlP/pDuJxKaPiLN 9fzLr0PB5qi5qX9GOax+CTLP6LWGIEI/siKfnOHCwCqH44FKrLffK72Xmm3eQeRQ LXuS9IVHvOV4wkuf4tA/jMlOwrh0QYkd5PP+A6DBI76Z5UuNrTNEYOC631fOGis= =Hifa -----END PGP SIGNATURE----- --Apple-Mail=_3FD7AFBE-E4B9-4162-9FAD-2781A0E01DFE-- From nobody Sun Apr 20 20:06: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 4C3DE1A0180 for ; Sun, 20 Apr 2014 20:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 ux9kKr4JetMW for ; Sun, 20 Apr 2014 20:06:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7F1A017F for ; Sun, 20 Apr 2014 20:06:10 -0700 (PDT) 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 BDH80573; Mon, 21 Apr 2014 03:06:04 +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, 21 Apr 2014 04:05:15 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 04:06:03 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 11:05:50 +0800 From: "Songhaibin (A)" To: Xuxiaohu , Ron Parker , "sfc@ietf.org" Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-00 Thread-Index: Ac9ZoN/oYzcTbeM+TgGZjuhgeN0QeQAOEnVQAMzZS6A= Date: Mon, 21 Apr 2014 03:05:49 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826BD18@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826BD18@NKGEML512-MBS.china.huawei.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.109] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F650BEE75nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jjjN7F_ZNb2M2enOV6psz57BJSs Subject: Re: [sfc] comments on draft-song-sfc-legacy-sf-mapping-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, 21 Apr 2014 03:06:16 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F650BEE75nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9uIGFuZCBYaWFvaHUsDQoNCg0KDQpUaGFuayB5b3UgZm9yIHRoZSB3b25kZXJmdWwgY29t bWVudHMuDQoNCg0KDQpXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyAmIGNsYXJpZmlj YXRpb25zPw0KDQoNCg0KVHJhbnNwYXJlbnQgU0Y6IEEgc2VydmljZSBmdW5jdGlvbiB0aGF0IGRv ZXMgbm90IGNoYW5nZSBhbnkgYml0IG9mIHRoZSBvcmlnaW5hbCBzZXJ2aWNlIHBhY2tldCBoZWFk ZXIgc2VudCB0byBpdCwgbmVpdGhlciBpbmplY3QgYW55IGluZGVwZW5kZW50IGZsb3dzIGludG8g dGhlIGRhdGEgc3RyZWFtLg0KDQoNCg0KDQoNCj5TZWN0aW9uIDMuMS4xLiBMYXllciAyIE1BQyBB ZGRyZXNzDQoNCg0KDQoqTGVnYWN5IHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBhYm92 ZSBsYXllciAzIHdvdWxkIHR5cGljYWxseSBub3QgYmUgYWJsZSB0byBwcmVzZXJ2ZSB0aGUgb3Jp Z2luYWwgU01BQy4gICBUYWtlIGZvciBleGFtcGxlIHRoZSBIVFRQIFByb3h5LCBhZ2Fpbi4gICBB IHR5cGljYWwgaW1wbGVtZW50YXRpb24gYWNjZXB0cyBzb2NrZXRzIG9uIHRoZSBjbGllbnQtZmFj aW5nIHNpZGUgYW5kIGJpbmRzL2Nvbm5lY3RzIHNvY2tldHMgb24gdGhlIHNlcnZlci1mYWNpbmcg c2lkZS4gICBPdXRnb2luZyBwYWNrZXRzIGFyZSBlbmNhcHN1bGF0ZWQgd2l0aCBhbiBFdGhlcm5l dCBoZWFkZXIgY29udGFpbmluZyB0aGUgbG9jYWwgTUFDIGFkZHJlc3MgYXMgdGhlIFNNQUMuDQoN Cg0KDQpJbiB0aGlzIGRvYywgdGhlIEhUVFAgUHJveHkgaXMgcmVnYXJkZWQgYXMgdGhlIG5vbi0g dHJhbnNwYXJlbnQgU0YuIFNvIHRoZSBtZXRob2RzIGZvciB0cmFuc3BhcmVudCBTRiBpcyBub3Qg YXBwbGljYWJsZS4NCg0KDQoNCg0KDQo+U2VjdGlvbiAzLjEuMi4gVkxBTg0KDQoNCg0KKlRoaXMg Y291bGQgYmUgcHJvYmxlbWF0aWMgaW4gYSB2aXJ0dWFsaXplZCBlbnZpcm9ubWVudCB3aGVyZSB0 aGUgY29ubmVjdGlvbiBmcm9tIHRoZSBTRkkgdG8gdGhlIFNGRSBtYXkgbm90IGJlIGEgZGlyZWN0 IHBoeXNpY2FsIGNvbm5lY3Rpb24uICAgQW4gU0ROLWJhc2VkIG5ldHdvcmsgdHlwaWNhbGx5IG93 bnMgdGhlIFZMQU4gSUQgYWxsb2NhdGlvbnMgYW5kIGludGVycHJldGF0aW9uLg0KDQoNCg0KVGhp cyBtZXRob2QgaXMgYXBwbGljYWJsZSBmb3IgdHJhbnNwYXJlbnQgU0YsIG1lYW53aGlsZSwgdGhl IGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgU0ZJIGFuZCBTRkUgaXMgaW4gYSBMMiBuZXR3b3JrLg0K DQoNCg0KPlNlY3Rpb24gMy4xLjMuIFFpblENCg0KDQoNCiogU2FtZSBjb21tZW50IGFzIGZvciBW TEFOLg0KDQoNCg0KDQoNClRoaXMgbWV0aG9kIGlzIGFwcGxpY2FibGUgZm9yIHRyYW5zcGFyZW50 IFNGLCBtZWFud2hpbGUsIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIFNGSSBhbmQgU0ZFIGlz IGluIGEgTDIgbmV0d29yay4NCg0KDQoNCg0KDQo+U2VjdGlvbiAzLjIuICBGb3IgTm9uLXRyYW5z cGFyZW50IFNlcnZpY2UgRnVuY3Rpb25zDQoNCg0KDQoqIFVzZSBvZiBjb250cm9sIHBsYW5lIHNp Z25hbGluZyBhdCBhIHBhY2tldCBvciBmbG93IGxldmVsIHdvdWxkIGJlIGRpZmZpY3VsdCB0byBz Y2FsZS4NCg0KDQoNCkZvciBub24tdHJhbnNwYXJlbnQgU0YsIHR3byBtZXRob2RzIGFyZSBpbnRy b2R1Y2VkIGluIHRoZSBkb2MsIG9uZSBpcyB1c2luZyA1LXR1cGxlIChhcHBsaWNhdGlvbiBjb25k aXRpb246IDUtdHVwbGUgb2YgdGhlIG9yaWdpbmFsIHBhY2tldCB3aWxsIG5vdCBiZSBtb2RpZmll ZCBieSB0aGUgbGVnYWN5IFNGKS4gVGhlIG90aGVyIGlzIHVzaW5nIGNvbnRyb2wgcGxhbmUsIGku ZS4gdGhlIGNvbnRyb2wgcGxhbmUgcHJvdmlkZXMgdGhlIG1hcHBpbmcgcnVsZXMuIFBsZWFzZSBz ZWUgdGhlIHRhYmxlIGZvciBkZXRhaWxzLiBJdCB3b3VsZCBiZSBkaWZmaWN1bHQgcGVyIHBhY2tl dCBsZXZlbCwgYnV0IGZvciBwZXIgZmxvdyBsZXZlbCwgaXRzIGNvbXBsZXhpdHkgaXMgc2ltaWxh ciBhcyBOQVQgaG90IHN0YW5kYnkuDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgVGFi bGUgMTogT3BlcmF0aW9uIENvbnNpZGVyYXRpb24NCg0KDQoNCg0KKy0tLS0tLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsN CnwgICAgICAgICAgIHxNZXRob2RzIHxJbmdyZXNzIEZsb3cgICAgIHxFZ3Jlc3MgRmxvdyAgfEFw cGxpY2F0aW9uICAgICAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8TWFwcGluZyAgICAgICAg ICB8TWFwcGluZyAgICAgIHxDb25kaXRpb24gICAgICAgICAgfA0KKy0tLS0tLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsN CnwgICAgICAgICAgIHxNQUMgICAgIHwxLjUtdHVwbGUtPlNvdXJjZXxTb3VyY2UgTUFDICAgfEwy IGhlYWRlciB3b24ndCAgICB8DQp8Rm9yIFRyYW5zLSB8QWRkcmVzcyB8TUFDIGFkZHJlc3MgICAg ICB8YWRkcmVzcy0+U0ZDIHxiZSBtb2RpZmllZCBieSAgICAgfA0KfHBhcmVudCBTRiAgfCAgICAg ICAgfDIuQW55IFNGQyAgICAgICAgfGhlYWRlciAgICAgICB8dGhlIFNGSS4gICAgICAgICAgIHwN CnwgICAgICAgICAgIHwgICAgICAgIHxwYWNrZXQtPlNvdXJjZSAgIHwgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8TUFDIGFkZHJlc3MgICAg ICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0KfCAgICAgICAgICAgKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsN CnwgICAgICAgICAgIHxWTEFOICAgIHw1LXR1cGxlLT5WTEFOIElEIHxWTEFOIElELT5TRkMgfEwy IGhlYWRlciB3b24ndCAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8aGVhZGVyICAgICAgIHxiZSBtb2RpZmllZCBieSAgICAgfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8dGhlIFNGSS4gICAgICAgICAgIHwN CnwgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0rDQp8ICAgICAgICAgICB8UWluUSAgICB8NS10dXBsZS0+T3V0ZXIg ICB8T3V0ZXIgVkxBTiAgIHxUaGUgU0ZJIGlzIHJlcXVpcmVkfA0KfCAgICAgICAgICAgfCAgICAg ICAgfFZMQU4gSUQgICAgICAgICAgfElELT5TRkMgICAgICB8dG8gc3VwcG9ydCBRaW5RLiAgIHwN CnwgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHxoZWFkZXIgICAgICAgfEwy IGhlYWRlciB3b24ndCAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHxiZSBtb2RpZmllZCBieSAgICAgfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8dGhlIFNGSS4gICAgICAgICAgIHwN CnwgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0rDQp8ICAgICAgICAgICB8VlhMQU4gICB8NS10dXBsZS0+Vk5JICAg ICB8Vk5JLT5TRkMgICAgIHxUaGUgU0ZJIGlzIHJlcXVpcmVkfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfGhlYWRlciAgICAgICB8dG8gc3VwcG9ydCBWWExBTi4gIHwN CnwgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfEwy IGhlYWRlciB3b24ndCAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHxiZSBtb2RpZmllZCBieSAgICAgfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8dGhlIFNGSS4gICAgICAgICAgIHwN CistLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0rDQp8ICAgICAgICAgICB8NS10dXBsZSB8NS10dXBsZSAgICAgICAg ICB8NS10dXBsZSAgICAgIHxUaGUgNS10dXBsZSBvZiB0aGUgfA0KfEZvciAgICAgICAgfE1hcHBp bmcgfC0+NS10dXBsZSAgICAgICAgfC0+U0ZDIGhlYWRlciB8b3JpZ2luYWwgcGFja2V0ICAgIHwN CnxOb24tdHJhbnMtIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfHdv bid0IGJlIG1vZGlmaWVkICB8DQp8cGFyZW50IFNGICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHxieSB0aGUgU0ZJLiAgICAgICAgfA0KfCAgICAgICAgICAgKy0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsN CnwgICAgICAgICAgIHxDb250cm9sIHxlLmcuIDUtdHVwbGUgICAgIHxlLmcuIDUtdHVwbGUnfFRo ZSBTRkUgbXVzdCBiZSAgICB8DQp8ICAgICAgICAgICB8UGxhbmUgICB8LT41LXR1cGxlJyAgICAg ICB8LT5TRkMgaGVhZGVyIHxjb25maWd1cmVkIG9yIGJlICAgfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8YWJsZSB0byBvYnRhaW4gdGhlIHwN CnwgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfG1h cHBpbmcgcnVsZXMgb2YgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHx0aGUgU0ZJLiBUaGUgU0ZJICAgfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8b25seSBjaGFuZ2VzIHRoZSAgIHwN CnwgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfDUt dHVwbGUgYWNjb3JkaW5nICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHx0byB0aGUgNS10dXBsZSAgICAgfA0KfCAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8bWFwcGluZyBydWxlcy4gICAgIHwN CistLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzIQ0KDQotSGFpYmluDQoN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KDQo+IFNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAxNywgMjAxNCA5OjQ4IEFNDQoNCj4gVG86IFJvbiBQYXJrZXI7IHNmY0Bp ZXRmLm9yZw0KDQo+IFN1YmplY3Q6IFtzZmNdILTwuLQ6IGNvbW1lbnRzIG9uIGRyYWZ0LXNvbmct c2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLTAwDQoNCj4NCg0KPg0KDQo+ID4gLS0tLS3Tyrz+1K28/i0t LS0tDQoNCj4gPiC3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IFJvbiBQYXJrZXINCg0KPiA+ILeiy83KsbzkOiAyMDE0xOo01MIxN8jVIDI6MzgNCg0KPiA+IMrV vP7Iyzogc2ZjQGlldGYub3JnDQoNCj4gPiDW98ziOiBbc2ZjXSBjb21tZW50cyBvbiBkcmFmdC1z b25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMA0KDQo+ID4NCg0KPiA+IFRvIHRoZSBhdXRob3Jz IG9mIGRyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nOg0KDQo+ID4NCg0KPiA+IFRoYW5r IHlvdSBmb3IgY29udHJpYnV0aW5nIHRoaXMgd2VsbCB3cml0dGVuIGRyYWZ0LiAgIEkgdGhpbmsg dGhpcyBpcyBhIHZlcnkNCg0KPiA+IHdvcnRod2hpbGUgaXNzdWUgdG8gdGFja2xlLCBidXQgZG8g aGF2ZSBzb21lIGNvbmNlcm5zIGluIHRoZSBjdXJyZW50IHJldmlzaW9uDQoNCj4gb2YNCg0KPiA+ IHRoZSBkcmFmdC4gICBNeSBzcGVjaWZpYyBjb21tZW50cyBhcmUgYmVsb3cuDQoNCj4gPg0KDQo+ ID4gVGhhbmtzLg0KDQo+ID4NCg0KPiA+ICAgICBSb24NCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0K PiA+DQoNCj4gPiBTZWN0aW9uIDIuIFRlcm1pbm9sb2d5DQoNCj4gPg0KDQo+ID4gKiBTdWdnZXN0 IGVuaGFuY2luZyB5b3VyIGRlZmluaXRpb24gb2YgVHJhbnNwYXJlbnQgU0YgdG8gYWxzbyBzdGF0 ZSB0aGF0IGl0DQoNCj4gZG9lcw0KDQo+ID4gbm90IGluamVjdCBpbmRlcGVuZGVudCBmbG93cyBp bnRvIHRoZSBkYXRhIHN0cmVhbS4gICBGb3IgZXhhbXBsZSwgc29tZQ0KDQo+ID4gdHJhbnNwYXJl bnQgSFRUUCBQcm94aWVzIGFyZSBub3Qgc291cmNlLWlwIHRyYW5zcGFyZW50IGZvciBzb21lIG9y IGFsbA0KDQo+ID4gb2YgdGhlaXIgdXBzdHJlYW0gY29ubmVjdGlvbnMsIGluc3RlYWQgdXNpbmcg dGhlaXIgb3duIGxvb3BiYWNrIG9yDQoNCj4gPiBpbnRlcmZhY2UgSVAgYWRkcmVzc2VzLg0KDQo+ DQoNCj4gSSBhZ3JlZSB0aGF0IG5vIGluamVjdGlvbiBvZiBhZGRpdGlvbmFsIGZsb3dzIHNob3Vs ZCBiZSBhbm90aGVyIHJlcXVpcmVtZW50IGZvcg0KDQo+IHRyYW5zcGFyZW50IFNGLiBIb3dldmVy LCBJIHRoaW5rIHRoZSB0cmFuc3BhcmVudCBsZWdhY3kgU0Ygd2hpY2ggaXMgYXBwbGljYWJsZQ0K DQo+IGZvciBzZXJ2aWNlIGNoYWluIHNob3VsZCBhdCBsZWFzdCBtZWV0IHRoZSBmb2xsb3dpbmcg cmVxdWlyZW1lbnQ6IG5vIGNoYW5nZSB0bw0KDQo+IHRoZSA1LXR1cGxlIG9mIHRoZSBvcmlnaW5h bCBwYWNrZXQuIE90aGVyd2lzZSwgaXQgd291bGQgYmUgdmVyeSBoYXJkIG9yIGV2ZW4NCg0KPiBp bXBvc3NpYmxlIGZvciB0aGUgU0ZGIHRvIGRvIHRoZSBtYXBwaW5nIHdpdGhvdXQgdGhlIGFzc2lz dGFuY2UgZnJvbSB0aGUgU0YNCg0KPiAoZS5nLiwgcHJvdmlkZSB0aGUgbWFwcGluZ3MgY3JlYXRl ZCBvbiB0aGUgU0YgdG8gdGhlIFNGRikuIEdpdmVuIHRoZSBhYm92ZQ0KDQo+IHJlcXVpcmVtZW50 IGhhcyBiZWVuIG1ldCwgd2h5IG5vdCBkaXJlY3RseSB1c2UgdGhlIDUtdHVwbGUgZm9yIHRoZSBt YXBwaW5nDQoNCj4gcHVycG9zZT8NCg0KPg0KDQo+IEJlc3QgcmVnYXJkcywNCg0KPiBYaWFvaHUN Cg0KPg0KDQo+ID4gU2VjdGlvbiAzLjEuMS4gTGF5ZXIgMiBNQUMgQWRkcmVzcw0KDQo+ID4NCg0K PiA+ICogTGVnYWN5IHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBhYm92ZSBsYXllciAz IHdvdWxkIHR5cGljYWxseSBub3QgYmUNCg0KPiBhYmxlDQoNCj4gPiB0byBwcmVzZXJ2ZSB0aGUg b3JpZ2luYWwgU01BQy4gICBUYWtlIGZvciBleGFtcGxlIHRoZSBIVFRQIFByb3h5LCBhZ2Fpbi4N Cg0KPiBBDQoNCj4gPiB0eXBpY2FsIGltcGxlbWVudGF0aW9uIGFjY2VwdHMgc29ja2V0cyBvbiB0 aGUgY2xpZW50LWZhY2luZyBzaWRlIGFuZA0KDQo+ID4gYmluZHMvY29ubmVjdHMgc29ja2V0cyBv biB0aGUgc2VydmVyLWZhY2luZyBzaWRlLiAgIE91dGdvaW5nIHBhY2tldHMgYXJlDQoNCj4gPiBl bmNhcHN1bGF0ZWQgd2l0aCBhbiBFdGhlcm5ldCBoZWFkZXIgY29udGFpbmluZyB0aGUgbG9jYWwg TUFDIGFkZHJlc3MNCg0KPiA+IGFzIHRoZSBTTUFDLg0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+ ID4gU2VjdGlvbiAzLjEuMi4gVkxBTg0KDQo+ID4NCg0KPiA+ICogVGhpcyBjb3VsZCBiZSBwcm9i bGVtYXRpYyBpbiBhIHZpcnR1YWxpemVkIGVudmlyb25tZW50IHdoZXJlIHRoZQ0KDQo+IGNvbm5l Y3Rpb24NCg0KPiA+IGZyb20gdGhlIFNGSSB0byB0aGUgU0ZFIG1heSBub3QgYmUgYSBkaXJlY3Qg cGh5c2ljYWwgY29ubmVjdGlvbi4gICBBbg0KDQo+ID4gU0ROLWJhc2VkIG5ldHdvcmsgdHlwaWNh bGx5IG93bnMgdGhlIFZMQU4gSUQgYWxsb2NhdGlvbnMgYW5kDQoNCj4gaW50ZXJwcmV0YXRpb24u DQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPiBTZWN0aW9uIDMuMS4zLiBRaW5RDQoNCj4gPg0K DQo+ID4gKiBTYW1lIGNvbW1lbnQgYXMgZm9yIFZMQU4uDQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoN Cj4gPiBTZWN0aW9uIDMuMi4gIEZvciBOb24tdHJhbnNwYXJlbnQgU2VydmljZSBGdW5jdGlvbnMN Cg0KPiA+DQoNCj4gPiAqIFVzZSBvZiBjb250cm9sIHBsYW5lIHNpZ25hbGluZyBhdCBhIHBhY2tl dCBvciBmbG93IGxldmVsIHdvdWxkIGJlDQoNCj4gPiBkaWZmaWN1bHQgdG8gc2NhbGUuDQoNCj4g Pg0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KPiA+IHNmYyBtYWlsaW5nIGxpc3QNCg0KPiA+IHNmY0Bp ZXRmLm9yZw0KDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ IHNmYyBtYWlsaW5nIGxpc3QNCg0KPiBzZmNAaWV0Zi5vcmcNCg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_E33E01DFD5BEA24B9F3F18671078951F650BEE75nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ron and Xiaohu,

 

Thank you for the wonderful = comments.

 

What about the following cha= nges & clarifications?

 

Transparent SF: A service fu= nction that does not change any bit of the original service packet header s= ent to it, neither inject any independent flows into the data stream.<= /o:p>

 

 

>Section 3.1.1. Layer 2 M= AC Address

 

*Legacy service functions th= at operate above layer 3 would typically not be able to preserve the origin= al SMAC.   Take for example the HTTP Proxy, again.   A = typical implementation accepts sockets on the client-facing side and binds/connects sockets on the server-facing side.   Out= going packets are encapsulated with an Ethernet header containing the local= MAC address as the SMAC.

 

In this doc, the HTTP Proxy = is regarded as the non- transparent SF. So the methods for transparent SF i= s not applicable.

 

 

>Section 3.1.2. VLAN=

 

*This could be problematic i= n a virtualized environment where the connection from the SFI to the SFE ma= y not be a direct physical connection.   An SDN-based network typ= ically owns the VLAN ID allocations and interpretation.

 

This method is applicable fo= r transparent SF, meanwhile, the connection between the SFI and SFE is in a= L2 network.

 

>Section 3.1.3. QinQ=

 

* Same comment as for VLAN.<= o:p>

 

 

This method is applicable fo= r transparent SF, meanwhile, the connection between the SFI and SFE is in a= L2 network.

 

 

>Section 3.2.  For N= on-transparent Service Functions

 

* Use of control plane signa= ling at a packet or flow level would be difficult to scale.

 

For non-transparent SF, two = methods are introduced in the doc, one is using 5-tuple (application condit= ion: 5-tuple of the original packet will not be modified by the legacy SF).= The other is using control plane, i.e. the control plane provides the mapping rules. Please see the table for det= ails. It would be difficult per packet level, but for per flow level, its c= omplexity is similar as NAT hot standby.

 

 

    &nbs= p;            &= nbsp;   Table 1: Operation Consideration

 

 

+-----------+--------+-----------= ------+-------------+-------------------+

|       &n= bsp;   |Methods |Ingress Flow     |Egress Flo= w  |Application        |=

|       &n= bsp;   |        |Mapping =          |Mapping   =    |Condition        &nbs= p; |

+-----------+--------+-----------= ------+-------------+-------------------+

|       &n= bsp;   |MAC     |1.5-tuple->Source|Source = MAC   |L2 header won't    |

|For Trans- |Address |MAC address  =     |address->SFC |be modified by    = |

|parent SF  |    &nb= sp;   |2.Any SFC        |heade= r       |the SFI.    &nbs= p;      |

|       &n= bsp;   |        |packet->So= urce   |         &nb= sp;   |         &nbs= p;         |

|       &n= bsp;   |        |MAC address&n= bsp;     |       &nb= sp;     |       &nbs= p;           |=

|       &n= bsp;   +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |VLAN    |5-tuple->VLAN ID |VLAN ID->= SFC |L2 header won't    |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |header       |be modified by &= nbsp;   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI.         &nbs= p; |

|       &n= bsp;   +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |QinQ    |5-tuple->Outer   |Ou= ter VLAN   |The SFI is required|

|       &n= bsp;   |        |VLAN ID =          |ID->SFC  &nb= sp;   |to support QinQ.   |

|       &n= bsp;   |        |  &= nbsp;            &nb= sp; |header       |L2 header won't =    |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |be modified by     |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI.         &nbs= p; |

|       &n= bsp;   +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |VXLAN   |5-tuple->VNI    = ; |VNI->SFC     |The SFI is required|

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |header       |to support VXLAN.&nbs= p; |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |L2 header won't    |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |be modified by     |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI.         &nbs= p; |

+-----------+--------+-----------= ------+-------------+-------------------+

|       &n= bsp;   |5-tuple |5-tuple       = ;   |5-tuple      |The 5-tuple of the |<= o:p>

|For       = ; |Mapping |->5-tuple        |->SF= C header |original packet    |

|Non-trans- |     &n= bsp;  |          &nb= sp;      |      &nbs= p;      |won't be modified  |

|parent SF  |    &nb= sp;   |         &nbs= p;       |      = ;       |by the SFI.    &= nbsp;   |

|        &= nbsp;  +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |Control |e.g. 5-tuple     |e.g. 5-tup= le'|The SFE must be    |

|       &n= bsp;   |Plane   |->5-tuple'    &= nbsp;  |->SFC header |configured or be   |

|       &n= bsp;   |        |  &= nbsp;            &nb= sp; |           = ;  |able to obtain the |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |mapping rules of   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI. The SFI   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |only changes the   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |5-tuple according  |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |to the 5-tuple     |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |mapping rules.     |

+-----------+--------+-----------= ------+-------------+-------------------+

 

 

Best Regards!

-Haibin

 

> -----Original Message--= ---

> From: sfc [mailto:sfc-b= ounces@ietf.org] On Behalf Of Xuxiaohu

> Sent: Thursday, April 1= 7, 2014 9:48 AM

> To: Ron Parker; sfc@iet= f.org

> Subject: [sfc] <= span style=3D"font-family:=CB=CE=CC=E5">=B4=F0=B8=B4: comments on draft-song-sfc-legacy-sf-mapping-00

>

>

> > -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> > =B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA=B1=ED Ron Parker

> > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA<= span lang=3D"EN-US">4=D4=C2= 17=C8=D5 2:38

> > =CA=D5=BC=FE=C8=CB: sfc@ietf.org

> > =D6=F7=CC=E2: [sf= c] comments on draft-song-sfc-legacy-sf-mapping-00

> ><= /p>

> > To the authors of = draft-song-sfc-legacy-sf-mapping:

> ><= /p>

> > Thank you for cont= ributing this well written draft.   I think this is a very

> > worthwhile issue t= o tackle, but do have some concerns in the current revision

> of

> > the draft. &n= bsp; My specific comments are below.

> ><= /p>

> > Thanks.=

> ><= /p>

> >   &= nbsp; Ron

> ><= /p>

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 2. Termino= logy

> ><= /p>

> > * Suggest enhancin= g your definition of Transparent SF to also state that it=

> does<= /p>

> > not inject indepen= dent flows into the data stream.   For example, some

> > transparent HTTP P= roxies are not source-ip transparent for some or all

> > of their upstream = connections, instead using their own loopback or

> > interface IP addre= sses.

>

> I agree that no injecti= on of additional flows should be another requirement for<= /p>

> transparent SF. However= , I think the transparent legacy SF which is applicable

> for service chain shoul= d at least meet the following requirement: no change to

> the 5-tuple of the orig= inal packet. Otherwise, it would be very hard or even

> impossible for the SFF = to do the mapping without the assistance from the SF

> (e.g., provide the mapp= ings created on the SF to the SFF). Given the above

> requirement has been me= t, why not directly use the 5-tuple for the mapping

> purpose?

>

> Best regards,

> Xiaohu

>

> > Section 3.1.1. Lay= er 2 MAC Address

> ><= /p>

> > * Legacy service f= unctions that operate above layer 3 would typically not be

> able<= /p>

> > to preserve the or= iginal SMAC.   Take for example the HTTP Proxy, again.=

> A

> > typical implementa= tion accepts sockets on the client-facing side and

> > binds/connects soc= kets on the server-facing side.   Outgoing packets are=

> > encapsulated with = an Ethernet header containing the local MAC address

> > as the SMAC.<= /o:p>

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 3.1.2. VLA= N

> ><= /p>

> > * This could be pr= oblematic in a virtualized environment where the

> connection

> > from the SFI to th= e SFE may not be a direct physical connection.   An

> > SDN-based network = typically owns the VLAN ID allocations and

> interpretation.

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 3.1.3. Qin= Q

> ><= /p>

> > * Same comment as = for VLAN.

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 3.2. = For Non-transparent Service Functions

> ><= /p>

> > * Use of control p= lane signaling at a packet or flow level would be

> > difficult to scale= .

> ><= /p>

> ><= /p>

> ><= /p>

> ><= /p>

> > __________________= _____________________________

> > sfc mailing list

> > sfc@ietf.org<= /o:p>

> > https://www.ietf.o= rg/mailman/listinfo/sfc

> _______________________= ________________________

> sfc mailing list

> sfc@ietf.org=

> https://www.ietf.org/ma= ilman/listinfo/sfc

--_000_E33E01DFD5BEA24B9F3F18671078951F650BEE75nkgeml501mbschi_-- From nobody Sun Apr 20 20:07: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 D794C1A0180 for ; Sun, 20 Apr 2014 20:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 2rMvvAL9k7dD for ; Sun, 20 Apr 2014 20:07:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D05641A017F for ; Sun, 20 Apr 2014 20:07:28 -0700 (PDT) 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 BDH80774; Mon, 21 Apr 2014 03:07:23 +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, 21 Apr 2014 04:05:48 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 04:07:22 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.143]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 11:07:13 +0800 From: "Liushucheng (Will)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-liu-sfc-use-cases-05.txt Thread-Index: AQHPXQPhwvVTJXtidkyZNukBkH9CTZsbTerw Date: Mon, 21 Apr 2014 03:07:12 +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.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iuaFjJyNyp0FowQiZ83qgdVxaY0 Cc: "draft-liu-sfc-use-cases@tools.ietf.org" Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-05.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, 21 Apr 2014 03:07:31 -0000 SGkgYWxsLA0KDQpCYXNlZCBvbiBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbnMgaW4gYm90aCBvbi1s aXN0IGFuZCBvZmYtbGlzdCwgd2UndmUgdXBkYXRlZCBvdXIgdXNlIGNhc2UgZHJhZnQgYWdhaW4u IFRoZSBtYWluIHVwZGF0ZXMgb2YgdmVyc2lvbiAwNSBmcm9tIDAzIGFyZSBzdW1tYXJpemVkIGJl bG93Og0KMS4gQSBwYXJhZ3JhcGggYWJvdXQgQnJvYWRiYW5kIEZvcnVtIChCQkYpIHdhcyBhZGRl ZCBpbiBTZWN0aW9uIDMuMS4gDQoyLiBBIHN1YnNlY3Rpb24gYWJvdXQgQ2hhaW4gaW4gQ2xvdWQg Q1BFIHdhcyBhZGRlZCBpbiAzLjUuDQozLiBTZWN0aW9uIDQgaGFzIGJlZW4gbW9kaWZpZWQgYSBs b3QuIFBlci1zZXJ2aWNlIFBlci11c2VyL3N1YnNjcmlwdGlvbiwgVEUtT3JpZW50ZWQgU0ZDIGNh c2VzIHdlcmUgYWRkZWQuDQo0LiBBIHN1YnNlY3Rpb24gYWJvdXQgUmVjdXJzaXZlIFNGQyB3YXMg YWRkZWQgaW4gNC43Lg0KVGhhbmtzIHRvIGFsbCB0aGVzZSBlZmZvcnRzLg0KDQpBbnkgY29tbWVu dHMgd2lsbCBiZSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcywNCldpbGwgKFNodWNoZW5nIExJVSkN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwg QXByaWwgMjEsIDIwMTQgOTo0OSBBTQ0KVG86IE5pY29sYWkgTGV5bWFubjsgSG9uZ3l1IExpIChK dWxpbyk7IExpdXNodWNoZW5nIChXaWxsKTsgUWlvbmcgU3VuOyBIdWFuZ3lvbmcgKE9saXZlcik7 IEhvbmd5dSBMaSAoSnVsaW8pOyBNb2hhbWVkIEJvdWNhZGFpcjsgQ2h1b25nIFBoYW07IExpdXNo dWNoZW5nIChXaWxsKTsgUWlvbmcgU3VuOyBaaGVuIENhbzsgQ2h1b25nIFBoYW07IE1vaGFtZWQg Qm91Y2FkYWlyOyBaaGVuIENhbzsgTmljb2xhaSBMZXltYW5uOyBIdWFuZ3lvbmcgKE9saXZlcikN ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LXNmYy11c2Ut Y2FzZXMtMDUudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS1zZmMtdXNl LWNhc2VzLTA1LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdpbGwoU2h1 Y2hlbmcpIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlk cmFmdC1saXUtc2ZjLXVzZS1jYXNlcw0KUmV2aXNpb246CTA1DQpUaXRsZToJCVNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgKFNGQykgVXNlIENhc2VzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA0LTIx DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxOQ0KVVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1zZmMtdXNl LWNhc2VzLTA1LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTA1DQpEaWZmOiAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGl1LXNmYy11c2Ut Y2FzZXMtMDUNCg0KQWJzdHJhY3Q6DQogICBUaGUgZGVsaXZlcnkgb2YgdmFsdWUtYWRkZWQgc2Vy dmljZXMgcmVsaWVzIG9uIHRoZSBpbnZvY2F0aW9uIG9mDQogICBhZHZhbmNlZCBTZXJ2aWNlIEZ1 bmN0aW9ucyBpbiBhIHNlcXVlbnRpYWwgb3JkZXIuICBUaGlzIG1lY2hhbmlzbSBpcw0KICAgY2Fs bGVkIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykuICBUaGUgc2V0IG9mIGludm9sdmVk IFNlcnZpY2UNCiAgIEZ1bmN0aW9ucyBhbmQgdGhlaXIgb3JkZXIgZGVwZW5kcyBvbiB0aGUgc2Vy dmljZSBjb250ZXh0Lg0KDQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2V0IG9mIHVzZSBj YXNlcyBvZiBTZXJ2aWNlIEZ1bmN0aW9uDQogICBDaGFpbmluZyAoU0ZDKS4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Apr 21 01:27: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 126E41A0189; Mon, 21 Apr 2014 01:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 sgjRMG1aOjjh; Mon, 21 Apr 2014 01:27:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 128071A01BD; Mon, 21 Apr 2014 01:26:55 -0700 (PDT) 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 BFW81279; Mon, 21 Apr 2014 08:26:50 +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; Mon, 21 Apr 2014 09:26:00 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 09:26:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 16:26:44 +0800 From: Xuxiaohu To: Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWwO2ZN9DNYdRwEi3MZ5fyWQNNpsbucIA Date: Mon, 21 Apr 2014 08:26:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-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.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JpM64bAZhqI4OUGrYvv5xU8h5GU Cc: "spring@ietf.org" Subject: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-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: Mon, 21 Apr 2014 08:27:05 -0000 SGkgUm9uLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVzcG9u c2UgaW5saW5lLg0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbiBQYXJrZXINCj4gt6LLzcqxvOQ6IDIwMTTE 6jTUwjE4yNUgMjA6NDMNCj4gytW8/sjLOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnDQo+ILOty806 IHNwcmluZ0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW3NmY10gV2h5IFRyYW5zcG9ydCBEZXBlbmRl bmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EDQo+IEFjdGlvbjogZHJhZnQtaWV0 Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+IA0KPiBYaWFvaHUsDQo+IA0KPiBXaGls ZSB0aGUgc3RhY2sgb2YgSVAgYWRkcmVzc2VzIGlzIHNpbXBsZSwgY29uY2VwdHVhbGx5LCBpdCBp cyBxdWl0ZSBleHBlbnNpdmUgb24NCj4gdGhlIHdpcmUsIGVzcGVjaWFsbHkgd2l0aCBJUHY2IGFk ZHJlc3Nlcy4NCg0KUGVyc29uYWxseSBJIGFncmVlLiBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRo ZXJlIGFyZSBhIGxvdCBvZiBTUHMgd2hvIGFyZSBpbiBmYXZvciBvZiBjYXJyeWluZyBhIHN0YWNr IG9mIElQdjYgYWRkcmVzc2VzIG9uIHRoZSBJUHY2IHBhY2tldC4gRm9yIG1vcmUgZGV0YWlscywg cGxlYXNlIHNlZSB0aGUgSVB2Ni1TUiB1c2UgY2FzZSBkcmFmdC4NCg0KPiBBIHN0YWNrIG9mIE1Q TFMgbGFiZWxzIGlzIGFsc28gY29uY2VwdHVhbGx5IHNpbXBsZSwgYnV0IHRoZSB1c2Ugb2YgTVBM UyBpcyBub3QNCj4gdW5pdmVyc2FsLCBlc3BlY2lhbGx5IHdpdGhpbiBkYXRhIGNlbnRlciBlbnZp cm9ubWVudHMuICAgQWxzbywgdGhpcyB1c2Ugb2YgdGhlDQoNCldpdGhpbiBkYXRhIGNlbnRlciBl bnZpcm9ubWVudHMgYXMgeW91IG1lbnRpb25lZCwgdGhlIE1QTFMgbGFiZWwgc3RhY2sgd291bGQg anVzdCBiZSB1c2VkIGZvciByZXByZXNlbnRpbmcgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgcGF0aCwg YW5kIHlvdSBjb3VsZCBzdGlsbCB1c2UgSVAtYmFzZWQgdHVubmVscyB0byBmb3J3YXJkIHBhY2tl dHMgZnJvbSBvbmUgc2VydmljZSBub2RlIHRvIGFub3RoZXIgKGZvciBtb3JlIGRldGFpbHMsIHNl ZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctaXNsYW5kcy1jb25u ZWN0aW9uLW92ZXItaXAtMDApLiBJbiBvdGhlciB3b3JkLCB0aGUgTVBMUyBsYWJlbCBzdGFjayBw bGF5cyB0aGUgc2ltaWxhciByb2xlIG9mIHRoZSBzZXJ2aWNlIHBhdGggSUQuDQoNCj4gTVBMUyBs YWJlbHMgaXMgc29tZXdoYXQgZGlmZmVyZW50LCBzZW1hbnRpY2FsbHksIGFuZCBjb3VsZCBjYXVz ZSBpc3N1ZXMgaWYgdXNlZA0KPiBjb25jdXJyZW50bHkgd2l0aCB0cmFkaXRpb25hbCBNUExTIHVz ZSBjYXNlcy4gICBFc3BlY2lhbGx5IGdpdmVuIHRoYXQgZXhpc3RpbmcNCj4gTVBMUyBsYWJlbHMg YXJlIGRvd25zdHJlYW0gYWxsb2NhdGVkIGJ1dCBTRkMgaXMgZXNzZW50aWFsbHkgc291cmNlIHJv dXRlZC4NCg0KQSBNUExTIGxhYmVsIHN0YWNrIGNhbiBiZSB1c2VkIHRvIHJlYWxpemUgdGhlIHNv dXJjZSByb3V0aW5nIHBhcmFkaWdtLCBzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTAxIGFuZCBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncmVkbGVyLXNwcmluZy1tcGxzLTAzLiANCg0KPiBQZXJo YXBzIHRoYXQgaXNzdWUgY291bGQgYmUgc29sdmVkLCBidXQgYXQgdGhlIGV4cGVuc2Ugb2YgYSBt b3JlIGNvbXBsZXggYW5kDQo+IGludmFzaXZlIGNvbnRyb2wgcGxhbmUuDQoNCkhvdyB0byBzaW1w bHkgdXNlIHRoZSBNUExTIGxhYmVsIHN0YWNrIHRvIHJlYWxpemUgdGhlIFNGQyBoYXMgYmVlbiBk ZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXNm Yy11c2UtY2FzZS0wMC4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCg0KPiAgICBSb24NCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFh1eGlhb2h1DQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTgsIDIwMTQgNTowMCBBTQ0KPiBUbzog c2ZjQGlldGYub3JnDQo+IENjOiBzcHJpbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3NmY10gV2h5 IFRyYW5zcG9ydCBEZXBlbmRlbmNlIGlzIGRlZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EDQo+ IEFjdGlvbjogZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQo+IA0KPiBI aSBhbGwsDQo+IA0KPiBJdCBzYWlkIGluIHNlY3Rpb24gMi42LiAgVHJhbnNwb3J0IERlcGVuZGVu Y2Ugb2YgdGhlIFBTIGRyYWZ0Og0KPiANCj4gICAiU2VydmljZSBmdW5jdGlvbnMgY2FuIGFuZCB3 aWxsIGJlIGRlcGxveWVkIGluIG5ldHdvcmtzIHdpdGggYSByYW5nZQ0KPiAgICBvZiB0cmFuc3Bv cnRzLCBpbmNsdWRpbmcgdW5kZXIgYW5kIG92ZXJsYXlzLiAgVGhlIGNvdXBsaW5nIG9mIHNlcnZp Y2UNCj4gICAgZnVuY3Rpb25zIHRvIHRvcG9sb2d5IHJlcXVpcmVzIHNlcnZpY2UgZnVuY3Rpb25z IHRvIHN1cHBvcnQgbWFueQ0KPiAgICB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbnMgb3IgZm9yIGEg dHJhbnNwb3J0IGdhdGV3YXkgZnVuY3Rpb24gdG8gYmUNCj4gICAgcHJlc2VudC4iDQo+IA0KPiBB c3N1bWUgdGhlIGZ1bmN0aW9uIG9mIHNlcnZpY2UgY2hhaW4gY2FuIGJlIGRpdmlkZWQgaW50byB0 d28gbGF5ZXJzOiBvbmUgaXMgdGhlDQo+IHNlcnZpY2UgcGF0aCBsYXllciB3aGljaCBpcyByZXNw b25zaWJsZSBmb3Igc3RlZXJpbmcgdGhlIHBhY2tldHMgYWxvbmcgdGhlIHNlcnZpY2UNCj4gcGF0 aCwgdGhlIG90aGVyIGlzIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGxheWVyIHdoaWNoIGlzIHJlc3Bv bnNpYmxlIGZvciBhcHBseWluZyBhDQo+IGdpdmVuIHNlcnZpY2UgdG8gdGhlIHBhY2tldC4gSSBh Z3JlZSB0aGF0IHRyYW5zcG9ydCBkZXBlbmRlbmNlIGlzIGJhZCBmb3IgdGhlDQo+IHNlcnZpY2Ug ZnVuY3Rpb24gbGF5ZXIuIEhvd2V2ZXIsIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdHJhbnNwb3J0 IGRlcGVuZGVuY2UNCj4gaXMgYWxzbyBiYWQgZm9yIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIuIElu IGZhY3QsIHRoZXJlIGFyZSBvbmx5IHR3byB1bmRlcmxheQ0KPiB0cmFuc3BvcnRzIChpLmUuLCBJ UCBhbmQgTVBMUykgd2hpY2ggbmVlZCB0byBiZSBjb25zaWRlcmVkIGZvciBzZXJ2aWNlIGNoYWlu Lg0KPiBUaGVyZWZvcmUsIHdlIGp1c3QgbmVlZCB0byBsZXZlcmFnZSB0aGUgc291cmNlIHJvdXRp bmcgY2FwYWJpbGl0eSBhc3NvY2lhdGVkIHdpdGgNCj4gSVAgb3IgTVBMUyB0byByZWFsaXplIHRo ZSBmdW5jdGlvbiBvZiB0aGUgc2VydmljZSBwYXRoIGxheWVyLiBUaGF0J3MgdG8gc2F5LCB3ZSBj YW4NCj4gdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiBJUCBhZGRyZXNzZXMgb3IgTVBMUyBsYWJlbHMg Y2FycmllZCBpbiB0aGUgcGFja2V0IHRvDQo+IHJlcHJlc2VudCB0aGUgc2VydmljZSBwYXRoLiBB IE1QTFMgbGFiZWwgaW4gdGhlIG9yZGVyZWQgbGlzdCBvZiBNUExTIGxhYmVscyAoaS5lLiwgYQ0K PiBNUExTIGxhYmVsIHN0YWNrKSBvciBhbiBJUCBhZGRyZXNzIGluIHRoZSBvcmRlcmVkIGxpc3Qg b2YgSVAgYWRkcmVzc2VzIGNhbiBiZSB1c2VkDQo+IHRvIGluZGljYXRlIGVpdGhlciBhIHNlcnZp Y2Ugbm9kZSB3aXRoaW4gdGhlIHNlcnZpY2UgcGF0aCBvciBhIHNlcnZpY2UgZnVuY3Rpb24gb24N Cj4gYSBnaXZlbiBzZXJ2aWNlIG5vZGUuIE5vdGUgdGhhdCBNUExTIGxhYmVscyBhbmQgSVAgYWRk cmVzc2VzIGhhdmUgYmVlbg0KPiBzdWNjZXNzZnVsbHkgdXNlZCBmb3IgaW5kaWNhdGluZyBzZXJ2 aWNlcyAoZS5nLiwgVlBOIGxhYmVscyBhbmQgbXVsdGljYXN0IGFkZHJlc3Nlcw0KPiBpbiB0aGUg cmFuZ2Ugb2YgMjI0LjAuMC54IG9yIEZGMDI6OnggKS4NCj4gDQo+IE9mIGNvdXJzZSwgaWYgeW91 IHN0aWxsIHRoaW5rIHRoZXJlIGFyZSB0b28gbXVjaCB3b3JrIHRvIGRvLCB5b3UgY291bGQgYWN0 dWFsbHkNCj4gb25seSBjb25zaWRlciB0aGUgTVBMUy1iYXNlZCBhcHByb2FjaCAoaS5lLiwgdXNp bmcgYSBNUExTIGxhYmVsIHN0YWNrIHRvDQo+IHJlcHJlc2VudCBhIHNlcnZpY2UgcGF0aCkgc2lu Y2UgaXQgY291bGQgYWxzbyBiZSBhcHBsaWNhYmxlIGluIGJvdGggSVB2NCBhbmQgSVB2Ng0KPiBu ZXR3b3JrcyB3aXRoIHRoZSBoZWxwIG9mIGFueSBraW5kIG9mIE1QTFMgb3ZlciBJUCBlbmNhcHN1 bGF0aW9uIHRlY2hub2xvZ2llcy4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0K PiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+ILeiy83K sbzkOiAyMDE0xOo01MIxN8jVIDM6MTgNCj4gPiDK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPiA+ILOty806IHNmY0BpZXRmLm9yZw0KPiA+INb3zOI6IFtzZmNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KPiA+DQo+ID4NCj4gPiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQo+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgV29ya2luZw0KPiA+IEdyb3VwIG9mIHRoZSBJRVRG Lg0KPiA+DQo+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIFByb2JsZW0gU3RhdGVtZW50DQo+ID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBQ YXVsIFF1aW5uDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBUaG9tYXMgTmFkZWF1DQo+ ID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0 LnR4dA0KPiA+IAlQYWdlcyAgICAgICAgICAgOiAxOA0KPiA+IAlEYXRlICAgICAgICAgICAgOiAy MDE0LTA0LTE2DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiA+ICAg IGRlcGxveW1lbnQgb2Ygc2VydmljZSBmdW5jdGlvbnMgKHN1Y2ggYXMgZmlyZXdhbGxzLCBsb2Fk IGJhbGFuY2VycykNCj4gPiAgICBpbiBsYXJnZS1zY2FsZSBlbnZpcm9ubWVudHMuICBUaGUgdGVy bSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzDQo+ID4gICAgdXNlZCB0byBkZXNjcmliZSB0 aGUgZGVmaW5pdGlvbiBhbmQgaW5zdGFudGlhdGlvbiBvZiBhbiBvcmRlcmVkIHNldA0KPiA+ICAg IG9mIGluc3RhbmNlcyBvZiBzdWNoIHNlcnZpY2UgZnVuY3Rpb25zLCBhbmQgdGhlIHN1YnNlcXVl bnQgInN0ZWVyaW5nIg0KPiA+ICAgIG9mIHRyYWZmaWMgZmxvd3MgdGhyb3VnaCB0aG9zZSBzZXJ2 aWNlIGZ1bmN0aW9ucy4NCj4gPg0KPiA+ICAgIFRoZSBzZXQgb2YgZW5hYmxlZCBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWlucyByZWZsZWN0IG9wZXJhdG9yIHNlcnZpY2UNCj4gPiAgICBvZmZlcmluZ3Mg YW5kIGlzIGRlc2lnbmVkIGluIGNvbmp1bmN0aW9uIHdpdGggYXBwbGljYXRpb24gZGVsaXZlcnkN Cj4gPiAgICBhbmQgc2VydmljZSBhbmQgbmV0d29yayBwb2xpY3kuDQo+ID4NCj4gPg0KPiA+IFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3Rh dGVtZW50Lw0KPiA+DQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtcHJv YmxlbS1zdGF0ZW1lbnQtMDQNCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNA0KPiA+DQo+ID4NCj4gPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzZmMgbWFpbGluZyBsaXN0DQo+ID4gc2Zj QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Zj IG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Mon Apr 21 03:29: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 10D5C1A01F4; Mon, 21 Apr 2014 03:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 LLFd2AyWdN_F; Mon, 21 Apr 2014 03:29:07 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD21A01EA; Mon, 21 Apr 2014 03:29:06 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so3780006iec.29 for ; Mon, 21 Apr 2014 03:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5LUc3UxhVajQZJRe83f/XpLfm7v1gSVTP5IOWaJRySA=; b=nIaV9oGGX6QgXp6LCnD5B9JIgmn6fhkEMjtV9VQybIBkF8/5nNixTSxS1ZQa7E4jIW AWNm5vWRPRFFyFUqhoQ1ssdlh/rUJR6DilYpXq1wdvRdExqqO5loNJW5p9jJ9/3UqLgk FVvN8m8n2R459V5cloSlN8h7QcSuwVcSqHOGsmcn5N1Dk3yesOUEhpN+5ZaKdLwhqeHg V2NFxV1tzzqjbMT/b6pzFO3rzHpPS2YguL8/dPCgD9ECvxXkbymvL1vJoEwKsofascxj jtYfeVJz5m+PZtVhdb5KaVytzqKr5xRA8qyl47XjmNJGSjgQ56+TM9PMQ/S7qpFH9Vjp Apuw== MIME-Version: 1.0 X-Received: by 10.43.141.12 with SMTP id jc12mr30586540icc.21.1398076141874; Mon, 21 Apr 2014 03:29:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 21 Apr 2014 03:29:01 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> Date: Mon, 21 Apr 2014 12:29:01 +0200 X-Google-Sender-Auth: IcSyOy8eHPYaWLpK0cwNvCGe6dg Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: multipart/alternative; boundary=001a11c24ac2ce339b04f78af710 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mnIskTlB9cWs_gc77CWCoA_DPmQ Cc: "spring@ietf.org" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-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: Mon, 21 Apr 2014 10:29:11 -0000 --001a11c24ac2ce339b04f78af710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xu, How to simply use the MPLS label stack to realize the SFC has been > described in http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. > Any comments are welcome. > =E2=80=8BThe draft says:=E2=80=8B "that packet, SN1 could further consume the metadata contained in the NSH and meanwhile decrease the service index value within the NSH by on =E2=80=8Be=E2=80=8B "=E2=80=8B I would observe after reading this draft that S =E2=80=8Bx service node may not be capable of handling NSH of any sort (inc= luding SR header - be it MPLS label stack or IPv6 EHs) therefor much more then just decreasing the index value is required at SNx. =E2=80=8BIt seems that to realize any service chain via most of today's ser= vice nodes a full removal of NSH and re-application is required at directly attached SNs. That actually means that network needs to carry the state pretty much out of band. Such state could be carried within routing protocols (today BGP is used for that in L3VPN case) or by new overlay control plane - same as is used to carry the metadata. Cheers, R. --001a11c24ac2ce339b04f78af710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xu,
How = to simply use the MPLS label stack to realize the SFC has been described in= http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. Any comments are welcome.

<= div>



--001a11c24ac2ce339b04f78af710-- From nobody Mon Apr 21 05:43: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 6CD4C1A020E for ; Mon, 21 Apr 2014 05:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 IGvj-Q1LSyg3 for ; Mon, 21 Apr 2014 05:43:45 -0700 (PDT) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5041A020A for ; Mon, 21 Apr 2014 05:43:45 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Mon, 21 Apr 2014 05:43:40 -0700 From: Ron Parker To: "Songhaibin (A)" , Xuxiaohu , "sfc@ietf.org" Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-00 Thread-Index: Ac9ZoN/oYzcTbeM+TgGZjuhgeN0QeQAOEnVQAMzZS6AAFH1PEA== Date: Mon, 21 Apr 2014 12:43:39 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826BD18@NKGEML512-MBS.china.huawei.com> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A814AAEMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8M2bKAARHYzBvf02SxGCXx12_rw Subject: Re: [sfc] comments on draft-song-sfc-legacy-sf-mapping-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, 21 Apr 2014 12:43:48 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814AAEMBX021W3CA2exch_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUsIGJlbG93Lg0KDQogICBSb24NCg0KDQpGcm9tOiBTb25naGFpYmlu IChBKSBbbWFpbHRvOmhhaWJpbi5zb25nQGh1YXdlaS5jb21dDQpTZW50OiBTdW5kYXksIEFwcmls IDIwLCAyMDE0IDExOjA2IFBNDQpUbzogWHV4aWFvaHU7IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogUkU6IGNvbW1lbnRzIG9uIGRyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBw aW5nLTAwDQoNCg0KSGkgUm9uIGFuZCBYaWFvaHUsDQoNCg0KDQpUaGFuayB5b3UgZm9yIHRoZSB3 b25kZXJmdWwgY29tbWVudHMuDQoNCg0KDQpXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgY2hhbmdl cyAmIGNsYXJpZmljYXRpb25zPw0KDQoNCg0KVHJhbnNwYXJlbnQgU0Y6IEEgc2VydmljZSBmdW5j dGlvbiB0aGF0IGRvZXMgbm90IGNoYW5nZSBhbnkgYml0IG9mIHRoZSBvcmlnaW5hbCBzZXJ2aWNl IHBhY2tldCBoZWFkZXIgc2VudCB0byBpdCwgbmVpdGhlciBpbmplY3QgYW55IGluZGVwZW5kZW50 IGZsb3dzIGludG8gdGhlIGRhdGEgc3RyZWFtLg0KDQoNCg0KUm9uPj4gZWRpdG9yaWFsIGNvbW1l bnQsIG9ubHkgqEMgY2hhbmdlIKGwbmVpdGhlciBpbmplY3ShsSB0byChsG5vciBzaGFsbCBpdCBp bmplY3ShsQ0KDQoNCg0KDQoNCj5TZWN0aW9uIDMuMS4xLiBMYXllciAyIE1BQyBBZGRyZXNzDQoN Cg0KDQoqTGVnYWN5IHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBhYm92ZSBsYXllciAz IHdvdWxkIHR5cGljYWxseSBub3QgYmUgYWJsZSB0byBwcmVzZXJ2ZSB0aGUgb3JpZ2luYWwgU01B Qy4gICBUYWtlIGZvciBleGFtcGxlIHRoZSBIVFRQIFByb3h5LCBhZ2Fpbi4gICBBIHR5cGljYWwg aW1wbGVtZW50YXRpb24gYWNjZXB0cyBzb2NrZXRzIG9uIHRoZSBjbGllbnQtZmFjaW5nIHNpZGUg YW5kIGJpbmRzL2Nvbm5lY3RzIHNvY2tldHMgb24gdGhlIHNlcnZlci1mYWNpbmcgc2lkZS4gICBP dXRnb2luZyBwYWNrZXRzIGFyZSBlbmNhcHN1bGF0ZWQgd2l0aCBhbiBFdGhlcm5ldCBoZWFkZXIg Y29udGFpbmluZyB0aGUgbG9jYWwgTUFDIGFkZHJlc3MgYXMgdGhlIFNNQUMuDQoNCg0KDQpJbiB0 aGlzIGRvYywgdGhlIEhUVFAgUHJveHkgaXMgcmVnYXJkZWQgYXMgdGhlIG5vbi0gdHJhbnNwYXJl bnQgU0YuIFNvIHRoZSBtZXRob2RzIGZvciB0cmFuc3BhcmVudCBTRiBpcyBub3QgYXBwbGljYWJs ZS4NCg0KDQoNCg0KDQo+U2VjdGlvbiAzLjEuMi4gVkxBTg0KDQoNCg0KKlRoaXMgY291bGQgYmUg cHJvYmxlbWF0aWMgaW4gYSB2aXJ0dWFsaXplZCBlbnZpcm9ubWVudCB3aGVyZSB0aGUgY29ubmVj dGlvbiBmcm9tIHRoZSBTRkkgdG8gdGhlIFNGRSBtYXkgbm90IGJlIGEgZGlyZWN0IHBoeXNpY2Fs IGNvbm5lY3Rpb24uICAgQW4gU0ROLWJhc2VkIG5ldHdvcmsgdHlwaWNhbGx5IG93bnMgdGhlIFZM QU4gSUQgYWxsb2NhdGlvbnMgYW5kIGludGVycHJldGF0aW9uLg0KDQoNCg0KVGhpcyBtZXRob2Qg aXMgYXBwbGljYWJsZSBmb3IgdHJhbnNwYXJlbnQgU0YsIG1lYW53aGlsZSwgdGhlIGNvbm5lY3Rp b24gYmV0d2VlbiB0aGUgU0ZJIGFuZCBTRkUgaXMgaW4gYSBMMiBuZXR3b3JrLg0KDQoNCg0KUm9u Pj4gVGhhdCBMMiBjb25uZWN0aW9uIGJldHdlZW4gU0ZJIGFuZCBTRkUgbWF5IGJlIGVtdWxhdGVk IHZpYSBTRE4uICAgSW4gdGhpcyBjYXNlLCB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgYSBWTEFOLXRy YW5zcGFyZW50IEUtTGluZS4NCg0KDQoNCg0KDQo+U2VjdGlvbiAzLjEuMy4gUWluUQ0KDQoNCg0K KiBTYW1lIGNvbW1lbnQgYXMgZm9yIFZMQU4uDQoNCg0KDQoNCg0KVGhpcyBtZXRob2QgaXMgYXBw bGljYWJsZSBmb3IgdHJhbnNwYXJlbnQgU0YsIG1lYW53aGlsZSwgdGhlIGNvbm5lY3Rpb24gYmV0 d2VlbiB0aGUgU0ZJIGFuZCBTRkUgaXMgaW4gYSBMMiBuZXR3b3JrLg0KDQoNCg0KDQoNCj5TZWN0 aW9uIDMuMi4gIEZvciBOb24tdHJhbnNwYXJlbnQgU2VydmljZSBGdW5jdGlvbnMNCg0KDQoNCiog VXNlIG9mIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIGF0IGEgcGFja2V0IG9yIGZsb3cgbGV2ZWwg d291bGQgYmUgZGlmZmljdWx0IHRvIHNjYWxlLg0KDQoNCg0KRm9yIG5vbi10cmFuc3BhcmVudCBT RiwgdHdvIG1ldGhvZHMgYXJlIGludHJvZHVjZWQgaW4gdGhlIGRvYywgb25lIGlzIHVzaW5nIDUt dHVwbGUgKGFwcGxpY2F0aW9uIGNvbmRpdGlvbjogNS10dXBsZSBvZiB0aGUgb3JpZ2luYWwgcGFj a2V0IHdpbGwgbm90IGJlIG1vZGlmaWVkIGJ5IHRoZSBsZWdhY3kgU0YpLiBUaGUgb3RoZXIgaXMg dXNpbmcgY29udHJvbCBwbGFuZSwgaS5lLiB0aGUgY29udHJvbCBwbGFuZSBwcm92aWRlcyB0aGUg bWFwcGluZyBydWxlcy4gUGxlYXNlIHNlZSB0aGUgdGFibGUgZm9yIGRldGFpbHMuIEl0IHdvdWxk IGJlIGRpZmZpY3VsdCBwZXIgcGFja2V0IGxldmVsLCBidXQgZm9yIHBlciBmbG93IGxldmVsLCBp dHMgY29tcGxleGl0eSBpcyBzaW1pbGFyIGFzIE5BVCBob3Qgc3RhbmRieS4NCg0KDQoNCg0KDQog ICAgICAgICAgICAgICAgICAgICBUYWJsZSAxOiBPcGVyYXRpb24gQ29uc2lkZXJhdGlvbg0KDQoN Cg0KDQorLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfE1ldGhvZHMgfEluZ3Jlc3MgRmxv dyAgICAgfEVncmVzcyBGbG93ICB8QXBwbGljYXRpb24gICAgICAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHxNYXBwaW5nICAgICAgICAgIHxNYXBwaW5nICAgICAgfENvbmRpdGlvbiAgICAgICAg ICB8DQorLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfE1BQyAgICAgfDEuNS10dXBsZS0+ U291cmNlfFNvdXJjZSBNQUMgICB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnxGb3IgVHJhbnMtIHxB ZGRyZXNzIHxNQUMgYWRkcmVzcyAgICAgIHxhZGRyZXNzLT5TRkMgfGJlIG1vZGlmaWVkIGJ5ICAg ICB8DQp8cGFyZW50IFNGICB8ICAgICAgICB8Mi5BbnkgU0ZDICAgICAgICB8aGVhZGVyICAgICAg IHx0aGUgU0ZJLiAgICAgICAgICAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfHBhY2tldC0+U291 cmNlICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHxNQUMgYWRkcmVzcyAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICB8DQp8ICAgICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfFZMQU4gICAgfDUtdHVwbGUtPlZM QU4gSUQgfFZMQU4gSUQtPlNGQyB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgIHxoZWFkZXIgICAgICAgfGJlIG1vZGlmaWVkIGJ5ICAg ICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHx0aGUgU0ZJLiAgICAgICAgICAgfA0KfCAgICAgICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAgICAgICAgIHxR aW5RICAgIHw1LXR1cGxlLT5PdXRlciAgIHxPdXRlciBWTEFOICAgfFRoZSBTRkkgaXMgcmVxdWly ZWR8DQp8ICAgICAgICAgICB8ICAgICAgICB8VkxBTiBJRCAgICAgICAgICB8SUQtPlNGQyAgICAg IHx0byBzdXBwb3J0IFFpblEuICAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgfGhlYWRlciAgICAgICB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfGJlIG1vZGlmaWVkIGJ5ICAg ICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHx0aGUgU0ZJLiAgICAgICAgICAgfA0KfCAgICAgICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAgICAgICAgIHxW WExBTiAgIHw1LXR1cGxlLT5WTkkgICAgIHxWTkktPlNGQyAgICAgfFRoZSBTRkkgaXMgcmVxdWly ZWR8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8aGVhZGVyICAgICAg IHx0byBzdXBwb3J0IFZYTEFOLiAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfGJlIG1vZGlmaWVkIGJ5ICAg ICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHx0aGUgU0ZJLiAgICAgICAgICAgfA0KKy0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAgICAgICAgIHw1 LXR1cGxlIHw1LXR1cGxlICAgICAgICAgIHw1LXR1cGxlICAgICAgfFRoZSA1LXR1cGxlIG9mIHRo ZSB8DQp8Rm9yICAgICAgICB8TWFwcGluZyB8LT41LXR1cGxlICAgICAgICB8LT5TRkMgaGVhZGVy IHxvcmlnaW5hbCBwYWNrZXQgICAgfA0KfE5vbi10cmFucy0gfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8d29uJ3QgYmUgbW9kaWZpZWQgIHwNCnxwYXJlbnQgU0YgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfGJ5IHRoZSBTRkkuICAgICAg ICB8DQp8ICAgICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfENvbnRyb2wgfGUuZy4gNS10dXBs ZSAgICAgfGUuZy4gNS10dXBsZSd8VGhlIFNGRSBtdXN0IGJlICAgIHwNCnwgICAgICAgICAgIHxQ bGFuZSAgIHwtPjUtdHVwbGUnICAgICAgIHwtPlNGQyBoZWFkZXIgfGNvbmZpZ3VyZWQgb3IgYmUg ICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHxhYmxlIHRvIG9idGFpbiB0aGUgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8bWFwcGluZyBydWxlcyBvZiAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfHRoZSBTRkkuIFRoZSBTRkkg ICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHxvbmx5IGNoYW5nZXMgdGhlICAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8NS10dXBsZSBhY2NvcmRpbmcgIHwNCnwgICAgICAgICAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfHRvIHRoZSA1LXR1cGxlICAg ICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHxtYXBwaW5nIHJ1bGVzLiAgICAgfA0KKy0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoNCg0KDQpCZXN0 IFJlZ2FyZHMhDQoNCi1IYWliaW4NCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cg0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFh1eGlhb2h1DQoNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDk6NDggQU0NCg0K PiBUbzogUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4g U3ViamVjdDogW3NmY10gtPC4tDogY29tbWVudHMgb24gZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNm LW1hcHBpbmctMDANCg0KPg0KDQo+DQoNCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCg0KPiA+ILei vP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9uIFBhcmtlcg0K DQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jTUwjE3yNUgMjozOA0KDQo+ID4gytW8/sjLOiBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCg0KPiA+INb3zOI6IFtzZmNdIGNvbW1lbnRzIG9u IGRyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLTAwDQoNCj4gPg0KDQo+ID4gVG8gdGhl IGF1dGhvcnMgb2YgZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmc6DQoNCj4gPg0KDQo+ ID4gVGhhbmsgeW91IGZvciBjb250cmlidXRpbmcgdGhpcyB3ZWxsIHdyaXR0ZW4gZHJhZnQuICAg SSB0aGluayB0aGlzIGlzIGEgdmVyeQ0KDQo+ID4gd29ydGh3aGlsZSBpc3N1ZSB0byB0YWNrbGUs IGJ1dCBkbyBoYXZlIHNvbWUgY29uY2VybnMgaW4gdGhlIGN1cnJlbnQgcmV2aXNpb24NCg0KPiBv Zg0KDQo+ID4gdGhlIGRyYWZ0LiAgIE15IHNwZWNpZmljIGNvbW1lbnRzIGFyZSBiZWxvdy4NCg0K PiA+DQoNCj4gPiBUaGFua3MuDQoNCj4gPg0KDQo+ID4gICAgIFJvbg0KDQo+ID4NCg0KPiA+DQoN Cj4gPg0KDQo+ID4NCg0KPiA+IFNlY3Rpb24gMi4gVGVybWlub2xvZ3kNCg0KPiA+DQoNCj4gPiAq IFN1Z2dlc3QgZW5oYW5jaW5nIHlvdXIgZGVmaW5pdGlvbiBvZiBUcmFuc3BhcmVudCBTRiB0byBh bHNvIHN0YXRlIHRoYXQgaXQNCg0KPiBkb2VzDQoNCj4gPiBub3QgaW5qZWN0IGluZGVwZW5kZW50 IGZsb3dzIGludG8gdGhlIGRhdGEgc3RyZWFtLiAgIEZvciBleGFtcGxlLCBzb21lDQoNCj4gPiB0 cmFuc3BhcmVudCBIVFRQIFByb3hpZXMgYXJlIG5vdCBzb3VyY2UtaXAgdHJhbnNwYXJlbnQgZm9y IHNvbWUgb3IgYWxsDQoNCj4gPiBvZiB0aGVpciB1cHN0cmVhbSBjb25uZWN0aW9ucywgaW5zdGVh ZCB1c2luZyB0aGVpciBvd24gbG9vcGJhY2sgb3INCg0KPiA+IGludGVyZmFjZSBJUCBhZGRyZXNz ZXMuDQoNCj4NCg0KPiBJIGFncmVlIHRoYXQgbm8gaW5qZWN0aW9uIG9mIGFkZGl0aW9uYWwgZmxv d3Mgc2hvdWxkIGJlIGFub3RoZXIgcmVxdWlyZW1lbnQgZm9yDQoNCj4gdHJhbnNwYXJlbnQgU0Yu IEhvd2V2ZXIsIEkgdGhpbmsgdGhlIHRyYW5zcGFyZW50IGxlZ2FjeSBTRiB3aGljaCBpcyBhcHBs aWNhYmxlDQoNCj4gZm9yIHNlcnZpY2UgY2hhaW4gc2hvdWxkIGF0IGxlYXN0IG1lZXQgdGhlIGZv bGxvd2luZyByZXF1aXJlbWVudDogbm8gY2hhbmdlIHRvDQoNCj4gdGhlIDUtdHVwbGUgb2YgdGhl IG9yaWdpbmFsIHBhY2tldC4gT3RoZXJ3aXNlLCBpdCB3b3VsZCBiZSB2ZXJ5IGhhcmQgb3IgZXZl bg0KDQo+IGltcG9zc2libGUgZm9yIHRoZSBTRkYgdG8gZG8gdGhlIG1hcHBpbmcgd2l0aG91dCB0 aGUgYXNzaXN0YW5jZSBmcm9tIHRoZSBTRg0KDQo+IChlLmcuLCBwcm92aWRlIHRoZSBtYXBwaW5n cyBjcmVhdGVkIG9uIHRoZSBTRiB0byB0aGUgU0ZGKS4gR2l2ZW4gdGhlIGFib3ZlDQoNCj4gcmVx dWlyZW1lbnQgaGFzIGJlZW4gbWV0LCB3aHkgbm90IGRpcmVjdGx5IHVzZSB0aGUgNS10dXBsZSBm b3IgdGhlIG1hcHBpbmcNCg0KPiBwdXJwb3NlPw0KDQo+DQoNCj4gQmVzdCByZWdhcmRzLA0KDQo+ IFhpYW9odQ0KDQo+DQoNCj4gPiBTZWN0aW9uIDMuMS4xLiBMYXllciAyIE1BQyBBZGRyZXNzDQoN Cj4gPg0KDQo+ID4gKiBMZWdhY3kgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBvcGVyYXRlIGFib3Zl IGxheWVyIDMgd291bGQgdHlwaWNhbGx5IG5vdCBiZQ0KDQo+IGFibGUNCg0KPiA+IHRvIHByZXNl cnZlIHRoZSBvcmlnaW5hbCBTTUFDLiAgIFRha2UgZm9yIGV4YW1wbGUgdGhlIEhUVFAgUHJveHks IGFnYWluLg0KDQo+IEENCg0KPiA+IHR5cGljYWwgaW1wbGVtZW50YXRpb24gYWNjZXB0cyBzb2Nr ZXRzIG9uIHRoZSBjbGllbnQtZmFjaW5nIHNpZGUgYW5kDQoNCj4gPiBiaW5kcy9jb25uZWN0cyBz b2NrZXRzIG9uIHRoZSBzZXJ2ZXItZmFjaW5nIHNpZGUuICAgT3V0Z29pbmcgcGFja2V0cyBhcmUN Cg0KPiA+IGVuY2Fwc3VsYXRlZCB3aXRoIGFuIEV0aGVybmV0IGhlYWRlciBjb250YWluaW5nIHRo ZSBsb2NhbCBNQUMgYWRkcmVzcw0KDQo+ID4gYXMgdGhlIFNNQUMuDQoNCj4gPg0KDQo+ID4NCg0K PiA+DQoNCj4gPiBTZWN0aW9uIDMuMS4yLiBWTEFODQoNCj4gPg0KDQo+ID4gKiBUaGlzIGNvdWxk IGJlIHByb2JsZW1hdGljIGluIGEgdmlydHVhbGl6ZWQgZW52aXJvbm1lbnQgd2hlcmUgdGhlDQoN Cj4gY29ubmVjdGlvbg0KDQo+ID4gZnJvbSB0aGUgU0ZJIHRvIHRoZSBTRkUgbWF5IG5vdCBiZSBh IGRpcmVjdCBwaHlzaWNhbCBjb25uZWN0aW9uLiAgIEFuDQoNCj4gPiBTRE4tYmFzZWQgbmV0d29y ayB0eXBpY2FsbHkgb3ducyB0aGUgVkxBTiBJRCBhbGxvY2F0aW9ucyBhbmQNCg0KPiBpbnRlcnBy ZXRhdGlvbi4NCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IFNlY3Rpb24gMy4xLjMuIFFpblEN Cg0KPiA+DQoNCj4gPiAqIFNhbWUgY29tbWVudCBhcyBmb3IgVkxBTi4NCg0KPiA+DQoNCj4gPg0K DQo+ID4NCg0KPiA+IFNlY3Rpb24gMy4yLiAgRm9yIE5vbi10cmFuc3BhcmVudCBTZXJ2aWNlIEZ1 bmN0aW9ucw0KDQo+ID4NCg0KPiA+ICogVXNlIG9mIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIGF0 IGEgcGFja2V0IG9yIGZsb3cgbGV2ZWwgd291bGQgYmUNCg0KPiA+IGRpZmZpY3VsdCB0byBzY2Fs ZS4NCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0KDQo+ ID4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gc2ZjIG1haWxpbmcgbGlzdA0KDQo+IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814AAEMBX021W3CA2exch_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Please see inline, below.

 

   Ron

 

 

From: = Songhaibin (A) [mailto:haibin.song@huawei.com]
Sent: Sunday, April 20, 2014 11:06 PM
To: Xuxiaohu; Ron Parker; sfc@ietf.org
Subject: RE: comments on draft-song-sfc-legacy-sf-mapping-00

 =

Hi Ron and Xiaohu,

 

Thank you for the wonderful comments.<= /p>

 

What about the following changes & clarificat= ions?

 

Transparent SF: A service function that does not = change any bit of the original service packet header sent to it, neither in= ject any independent flows into the data stream.

 

Ro= n>> editorial comment, only =A8C change =A1=B0neither inject=A1=B1 to= =A1=B0nor shall it inject=A1=B1

 

 

>Section 3.1.1. Layer 2 MAC Address=

 

*Legacy service functions that operate above laye= r 3 would typically not be able to preserve the original SMAC.   = Take for example the HTTP Proxy, again.   A typical implementatio= n accepts sockets on the client-facing side and binds/connects sockets on the server-facing side.   Outgoing packets are encaps= ulated with an Ethernet header containing the local MAC address as the SMAC= .

 

In this doc, the HTTP Proxy is regarded as the no= n- transparent SF. So the methods for transparent SF is not applicable.

 

 

>Section 3.1.2. VLAN

 

*This could be problematic in a virtualized envir= onment where the connection from the SFI to the SFE may not be a direct phy= sical connection.   An SDN-based network typically owns the VLAN = ID allocations and interpretation.

 

This method is applicable for transparent SF, mea= nwhile, the connection between the SFI and SFE is in a L2 network.

 

Ro= n>> That L2 connection between SFI and SFE may be emulated via SDN.&n= bsp;  In this case, that would need to be a VLAN-transparent E-Line.

 

 

>Section 3.1.3. QinQ

 

* Same comment as for VLAN.

 

 

This method is applicable for transparent SF, mea= nwhile, the connection between the SFI and SFE is in a L2 network.

 

 

>Section 3.2.  For Non-transparent Servic= e Functions

 

* Use of control plane signaling at a packet or f= low level would be difficult to scale.

 

For non-transparent SF, two methods are introduce= d in the doc, one is using 5-tuple (application condition: 5-tuple of the o= riginal packet will not be modified by the legacy SF). The other is using c= ontrol plane, i.e. the control plane provides the mapping rules. Please see the table for details. It would be = difficult per packet level, but for per flow level, its complexity is simil= ar as NAT hot standby.

 

 

        &= nbsp;            Tab= le 1: Operation Consideration

 

 

+-----------+--------+-----------------+----= ---------+-------------------+

|          = ; |Methods |Ingress Flow     |Egress Flow  |Applic= ation        |

|          = ; |        |Mapping   &nb= sp;      |Mapping      |C= ondition          |=

+-----------+--------+-----------------+----= ---------+-------------------+

|          = ; |MAC     |1.5-tuple->Source|Source MAC  = |L2 header won't    |

|For Trans- |Address |MAC address    &nb= sp; |address->SFC |be modified by     |

|parent SF  |       = |2.Any SFC        |header  &n= bsp;    |the SFI.       &= nbsp;   |

|          = ; |        |packet->Source  = ; |            = |            &= nbsp;      |

|          = ; |        |MAC address   = ;   |          =    |          &= nbsp;        |

|          = ; +--------+-----------------+-------------+---------------= ----+

|          = ; |VLAN    |5-tuple->VLAN ID |VLAN ID->SFC |L2 header = won't    |

|          = ; |        |    &nbs= p;            |heade= r       |be modified by   &nbs= p; |

|          = ; |        |    &nbs= p;            | = ;            |the SF= I.           |=

|          = ; +--------+-----------------+-------------+---------------= ----+

|          = ; |QinQ    |5-tuple->Outer   |Outer VLAN &= nbsp; |The SFI is required|

|          = ; |        |VLAN ID   &nb= sp;      |ID->SFC     = |to support QinQ.   |

|          = ; |        |    &nbs= p;            |heade= r       |L2 header won't    |<= o:p>

|          = ; |        |    &nbs= p;            | = ;            |be mod= ified by     |

|          = ; |        |    &nbs= p;            | = ;            |the SF= I.           |=

|          = ; +--------+-----------------+-------------+---------------= ----+

|          = ; |VXLAN   |5-tuple->VNI     |VNI->SFC&= nbsp;    |The SFI is required|

|          = ; |        |    &nbs= p;            |heade= r       |to support VXLAN.  |=

|          = ; |        |    &nbs= p;            | = ;            |L2 hea= der won't    |

|          = ; |        |    &nbs= p;            | = ;            |be mod= ified by     |

|          = ; |        |    &nbs= p;            | = ;            |the SF= I.           |=

+-----------+--------+-----------------+----= ---------+-------------------+

|          = ; |5-tuple |5-tuple          |= 5-tuple      |The 5-tuple of the |

|For        |Mapping |-&g= t;5-tuple        |->SFC header |origi= nal packet    |

|Non-trans- |        |&nb= sp;            =     |         &= nbsp;   |won't be modified  |

|parent SF  |       = |            &= nbsp;    |        &n= bsp;    |by the SFI.      &nbs= p; |

|          &nbs= p;+--------+-----------------+-------------+---------------= ----+

|          = ; |Control |e.g. 5-tuple     |e.g. 5-tuple'|The SFE mus= t be    |

|          = ; |Plane   |->5-tuple'       |-&= gt;SFC header |configured or be   |

|          = ; |        |    &nbs= p;            | = ;            |able t= o obtain the |

|          = ; |        |    &nbs= p;            | = ;            |mappin= g rules of   |

|          = ; |        |    &nbs= p;            | = ;            |the SF= I. The SFI   |

|          = ; |        |    &nbs= p;            | = ;            |only c= hanges the   |

|          = ; |        |    &nbs= p;            | = ;            |5-tupl= e according  |

|          = ; |        |    &nbs= p;            | = ;            |to the= 5-tuple     |

|          = ; |        |    &nbs= p;            | = ;            |mappin= g rules.     |

+-----------+--------+-----------------+----= ---------+-------------------+

 

 

Best Regards!

-Haibin

 

> -----Original Message-----

> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu

> Sent: Thursday, April 17, 2014 9:48 AM<= /o:p>

> To: Ron Parker; sfc@ietf.org

> Subject: [sfc] =B4=F0=B8=B4: comments on draft-song-sfc-legacy-sf-mapping-00

>

>

> > -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> > =B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA=B1=ED Ron P= arker

> > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C217=C8=D5 2:38

> > =CA=D5=BC=FE=C8=CB: sfc@ietf.org

> > =D6=F7=CC=E2: [sfc] comments on draft-song-sfc-legacy-sf-= mapping-00

> >

> > To the authors of draft-song-sfc-legacy= -sf-mapping:

> >

> > Thank you for contributing this well wr= itten draft.   I think this is a very

> > worthwhile issue to tackle, but do have= some concerns in the current revision

> of

> > the draft.   My specific comm= ents are below.

> >

> > Thanks.

> >

> >     Ron<= /p>

> >

> >

> >

> >

> > Section 2. Terminology

> >

> > * Suggest enhancing your definition of = Transparent SF to also state that it

> does

> > not inject independent flows into the d= ata stream.   For example, some

> > transparent HTTP Proxies are not source= -ip transparent for some or all

> > of their upstream connections, instead = using their own loopback or

> > interface IP addresses.

>

> I agree that no injection of additional flow= s should be another requirement for

> transparent SF. However, I think the transpa= rent legacy SF which is applicable

> for service chain should at least meet the f= ollowing requirement: no change to

> the 5-tuple of the original packet. Otherwis= e, it would be very hard or even

> impossible for the SFF to do the mapping wit= hout the assistance from the SF

> (e.g., provide the mappings created on the S= F to the SFF). Given the above

> requirement has been met, why not directly u= se the 5-tuple for the mapping

> purpose?

>

> Best regards,

> Xiaohu

>

> > Section 3.1.1. Layer 2 MAC Address=

> >

> > * Legacy service functions that operate= above layer 3 would typically not be

> able

> > to preserve the original SMAC. &nb= sp; Take for example the HTTP Proxy, again.

> A

> > typical implementation accepts sockets = on the client-facing side and

> > binds/connects sockets on the server-fa= cing side.   Outgoing packets are

> > encapsulated with an Ethernet header co= ntaining the local MAC address

> > as the SMAC.

> >

> >

> >

> > Section 3.1.2. VLAN

> >

> > * This could be problematic in a virtua= lized environment where the

> connection

> > from the SFI to the SFE may not be a di= rect physical connection.   An

> > SDN-based network typically owns the VL= AN ID allocations and

> interpretation.

> >

> >

> >

> > Section 3.1.3. QinQ

> >

> > * Same comment as for VLAN.<= /p>

> >

> >

> >

> > Section 3.2.  For Non-transparent = Service Functions

> >

> > * Use of control plane signaling at a p= acket or flow level would be

> > difficult to scale.

> >

> >

> >

> >

> > _______________________________________= ________

> > sfc mailing list

> > sfc@iet= f.org

> > https://www.ietf.org/mailman/listinfo/sfc

> ____________________________________________= ___

> sfc mailing list

> sfc@ietf.org=

> https://www.ietf.org/mailman/listinfo/sfc

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814AAEMBX021W3CA2exch_-- From nobody Mon Apr 21 08:36: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 904B91A018F for ; Mon, 21 Apr 2014 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 wVvic0p9cePg for ; Mon, 21 Apr 2014 08:36:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 77B751A0004 for ; Mon, 21 Apr 2014 08:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3608; q=dns/txt; s=iport; t=1398094582; x=1399304182; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3HJrqhXbslP9yhRBUUWMbxOJ+qiywIBudt7Z+3EuXWs=; b=WqTNyy4m02jxqcbvkaCRibihcbr7WM8KEUjWar5lAUct6EvCVunzhf+w OVP3EgnhTfKchY5mzc5+o5vcKSCLC/EgftW733s93Vy6C3oBMnSHs6k6B LldemqKzHYsOXR1j/NwI0ZEWiKmSz+ElEDT4HYMnRc2W4mAurXomN5Jw1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFAO85VVOtJV2Z/2dsb2JhbABZgkJET0sMvFKHPIEgFnSCJgEBBAEBARpRCxACAQgEOwcnCxQRAgQOBQmIOA3NaheOYgeDJIEUBJhukk+DMYIr X-IronPort-AV: E=Sophos;i="4.97,896,1389744000"; d="scan'208,217";a="319238987" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 21 Apr 2014 15:36:20 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3LFaKWR013990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 15:36:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.67]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 10:36:20 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpscjAeA Date: Mon, 21 Apr 2014 15:36:19 +0000 Message-ID: <73CC197D-D027-46D1-8B8B-A049E620AE49@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.155.158.223] Content-Type: multipart/alternative; boundary="_000_73CC197DD02746D18B8BA049E620AE49ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/d8q-GiImJJ2XatvHQUe70WdxnOw Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 15:36:30 -0000 --_000_73CC197DD02746D18B8BA049E620AE49ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I suport the adoption of this draft. Paul On Apr 18, 2014, at 3:29 PM, Jim Guichard (jguichar) > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_73CC197DD02746D18B8BA049E620AE49ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I suport the adoption of this draft.

Paul


On Apr 18, 2014, at 3:29 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_73CC197DD02746D18B8BA049E620AE49ciscocom_-- From nobody Mon Apr 21 08:37: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 602771A018E for ; Mon, 21 Apr 2014 08:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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.272, 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 wEnMf4kUjODt for ; Mon, 21 Apr 2014 08:37:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id E25AF1A0004 for ; Mon, 21 Apr 2014 08:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3708; q=dns/txt; s=iport; t=1398094669; x=1399304269; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WCw/bbMreH+38SQnIThRe/mB5hwkjLKHhLZAOvku2rM=; b=BLHbr+AMMiPCdKjGKwDB52+Vg+W4l7mxRgO74IABkFNCOicD3hsDgXft +DoG2xF7ocZQLh60RCX4ONKWDuMlzj+LJn57vPq0fqOveNwbk375B2cu+ x4LxcbAYQXYgUlhRMQz7HMzk7awK0mrSDDyuElncgis9Xnhgk0M2IsyJD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFAHM6VVOtJV2Y/2dsb2JhbABZgkJET0sMvFKHPIEgFnSCJgEBBAEBARpRCxACAQgEOwcnCxQRAgQOBQmIOA3NaReOYgeDJIEUBJhukk+DMYIr X-IronPort-AV: E=Sophos; i="4.97,896,1389744000"; d="scan'208,217"; a="37467479" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 21 Apr 2014 15:37:48 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3LFbmNW009573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 15:37:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.67]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 10:37:48 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZscjG+A Date: Mon, 21 Apr 2014 15:37:47 +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.155.158.223] Content-Type: multipart/alternative; boundary="_000_EB0AFAFA728442038CA326A8A52FB89Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5WKtupa8lu1QZUmNJNOE6i50mcU Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 15:37:55 -0000 --_000_EB0AFAFA728442038CA326A8A52FB89Bciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support this draft, it covers an important deployment where SFC is very r= elevant. Paul On Apr 18, 2014, at 3:31 PM, Jim Guichard (jguichar) > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_EB0AFAFA728442038CA326A8A52FB89Bciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7AEAAF8D47DDE94584A3EB3B62FB3C92@emea.cisco.com> Content-Transfer-Encoding: quoted-printable I support this draft, it covers an important deployment where SFC is very r= elevant.

Paul



On Apr 18, 2014, at 3:31 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_EB0AFAFA728442038CA326A8A52FB89Bciscocom_-- From nobody Mon Apr 21 10:18: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 7E5051A024C for ; Mon, 21 Apr 2014 10:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 ir7VWIWVO9TY for ; Mon, 21 Apr 2014 10:18:03 -0700 (PDT) Received: from smtp1.riverbed.com (incomingmail.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6671A0238 for ; Mon, 21 Apr 2014 10:18:03 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 21 Apr 2014 10:17:56 -0700 Received: from SFO1EXC-MBXP07.nbttech.com ([fe80::470:1b85:695b:b44e]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.02.0328.009; Mon, 21 Apr 2014 10:17:54 -0700 From: Kevin Glavin To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPXYWgZeMIdi+ZfEiuJhVtVLa9OQ== Date: Mon, 21 Apr 2014 17:17:54 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D93A355@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.251] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D93A355SFO1EXCMBXP07nb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/W9TgLnUgal69PO2SEDqqjVcgnr8 Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 17:18:07 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D93A355SFO1EXCMBXP07nb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I suport the adoption draft-haeffner-sfc-use-case-mobility-01 Kevin From: "Jim Guichard (jguichar)" > Date: Friday, April 18, 2014 3:29 PM To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_9EA32E60D7600C43B6FE22876DF564C81D93A355SFO1EXCMBXP07nb_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I suport the adoption draft-haeffner-sfc-use-case-= mobility-01 

Kevin

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, April 18, 2014 3:29 P= M
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-haeffner-sfc-use-case-mobility-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
 --_000_9EA32E60D7600C43B6FE22876DF564C81D93A355SFO1EXCMBXP07nb_-- From nobody Mon Apr 21 10:18: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 BE9D21A0250 for ; Mon, 21 Apr 2014 10:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 KM9rSSZ05U-R for ; Mon, 21 Apr 2014 10:18:33 -0700 (PDT) Received: from smtp1.riverbed.com (eng.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1C1A024B for ; Mon, 21 Apr 2014 10:18:33 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 21 Apr 2014 10:18:28 -0700 Received: from SFO1EXC-MBXP07.nbttech.com ([fe80::470:1b85:695b:b44e]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%15]) with mapi id 14.02.0328.009; Mon, 21 Apr 2014 10:18:27 -0700 From: Kevin Glavin To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPXYW0U8UhsrhhTUWWEhfLxMVVkQ== Date: Mon, 21 Apr 2014 17:18:26 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D93A36A@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.251] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D93A36ASFO1EXCMBXP07nb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mJBN7aKisudPyYqA4SkXYuRLm7s Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 17:18:38 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D93A36ASFO1EXCMBXP07nb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the adoption of draft-kumar-sfc-dc-use-cases-01 Kevin From: "Jim Guichard (jguichar)" > Date: Friday, April 18, 2014 3:31 PM To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_9EA32E60D7600C43B6FE22876DF564C81D93A36ASFO1EXCMBXP07nb_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I support the adoption of draft-kumar-sfc-dc-use-cases-01
Kevin


From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, April 18, 2014 3:31 P= M
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-kumar-sfc-dc-use-cases-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
--_000_9EA32E60D7600C43B6FE22876DF564C81D93A36ASFO1EXCMBXP07nb_-- From nobody Mon Apr 21 10:22: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 0660E1A01FA for ; Mon, 21 Apr 2014 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 80Uia5yAyl5U for ; Mon, 21 Apr 2014 10:22:47 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id D42731A0015 for ; Mon, 21 Apr 2014 10:22:47 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3LHMeag026862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Apr 2014 12:22:41 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3LHMd7J005612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 19:22:39 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.14]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 21 Apr 2014 19:22:39 +0200 From: "Henderickx, Wim (Wim)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPXYZL7+F6uKRIpEaWLTTWMQ9U+w== Date: Mon, 21 Apr 2014 17:22:38 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF7B2060C3F7Awimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NS-cfdt_FCMRC_-xBqfY8Xevjl4 Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 17:22:52 -0000 --_000_CF7B2060C3F7Awimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support, good baseline From: "Jim Guichard (jguichar)" > Date: Saturday 19 April 2014 00:29 To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF7B2060C3F7Awimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Support, good baseline 

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Saturday 19 April 2014 00:29<= br> To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-haeffner-sfc-use-case-mobility-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
 --_000_CF7B2060C3F7Awimhenderickxalcatellucentcom_-- From nobody Mon Apr 21 10:23: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 48F4E1A0228 for ; Mon, 21 Apr 2014 10:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 VE0Jb_dN0y9F for ; Mon, 21 Apr 2014 10:23:01 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 329411A0226 for ; Mon, 21 Apr 2014 10:23:01 -0700 (PDT) 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 s3LHMr8d007179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Apr 2014 12:22:54 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s3LHMqnu008901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 19:22:52 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.14]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 21 Apr 2014 19:22:52 +0200 From: "Henderickx, Wim (Wim)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPXYZTU8UhsrhhTUWWEhfLxMVVkQ== Date: Mon, 21 Apr 2014 17:22:52 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_CF7B2073C3F7Ewimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xWZtq1nHTNN16f6Ilk5dhCJ_uFs Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 17:23:05 -0000 --_000_CF7B2073C3F7Ewimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support, good baseline From: "Jim Guichard (jguichar)" > Date: Saturday 19 April 2014 00:31 To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF7B2073C3F7Ewimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Support, good baseline 

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Saturday 19 April 2014 00:31<= br> To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-kumar-sfc-dc-use-cases-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
--_000_CF7B2073C3F7Ewimhenderickxalcatellucentcom_-- From nobody Mon Apr 21 10:30: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 ECA611A0225 for ; Mon, 21 Apr 2014 10:29:59 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EgTzhRmr0gFC for ; Mon, 21 Apr 2014 10:29:57 -0700 (PDT) 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 9EB361A01FA for ; Mon, 21 Apr 2014 10:29:57 -0700 (PDT) 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.0174.001; Mon, 21 Apr 2014 10:29:52 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpscV+YA Date: Mon, 21 Apr 2014 17:29:51 +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_CDF2F015F4429F458815ED2A6C2B6B0B1A814E29MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_qHkIrsT9YVlsVhzaX0NxBWamvU Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 17:30:00 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814E29MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 6:30 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814E29MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 6:30 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/dr= aft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814E29MBX021W3CA2exch_-- From nobody Mon Apr 21 10:31: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 AB3641A0242 for ; Mon, 21 Apr 2014 10:31:36 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cWo_VBbG9DOv for ; Mon, 21 Apr 2014 10:31:35 -0700 (PDT) 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 E22741A0234 for ; Mon, 21 Apr 2014 10:31:34 -0700 (PDT) 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.0174.001; Mon, 21 Apr 2014 10:31:29 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZscWFiA Date: Mon, 21 Apr 2014 17:31:29 +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_CDF2F015F4429F458815ED2A6C2B6B0B1A814E3CMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dnq9fmPdPHIrCZhavcO17nJX3kk Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 17:31:36 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814E3CMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 6:32 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814E3CMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 6:32 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/draft-kuma= r-sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A814E3CMBX021W3CA2exch_-- From nobody Mon Apr 21 11:50: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 8896F1A023D for ; Mon, 21 Apr 2014 11:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 bf-ycjV5bhin for ; Mon, 21 Apr 2014 11:49:57 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE751A023B for ; Mon, 21 Apr 2014 11:49:57 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Mon, 21 Apr 2014 14:49:51 -0400 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPXYZTU8UhsrhhTUWWEhfLxMVVkZscacEw Date: Mon, 21 Apr 2014 18:49:50 +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: [192.168.200.52] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98309DE42Fwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/T5wqpZMWAmfa-Hvj1RgEPHLw8c4 Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 18:50:01 -0000 --_000_E8355113905631478EFF04F5AA706E98309DE42Fwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: "Jim Guichard (jguichar)" > Date: Saturday 19 April 2014 00:31 To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_E8355113905631478EFF04F5AA706E98309DE42Fwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Saturday 19 April 2014 00:31
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/draft-kuma= r-sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_E8355113905631478EFF04F5AA706E98309DE42Fwtlexchp2sandvi_-- From nobody Mon Apr 21 12:00: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 B88D01A0262 for ; Mon, 21 Apr 2014 12:00:08 -0700 (PDT) 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 2au9DJYwemR5 for ; Mon, 21 Apr 2014 12:00:07 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2BF1A026F for ; Mon, 21 Apr 2014 12:00:06 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3LI18ch018321; Mon, 21 Apr 2014 11:59:56 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1kcfjk8hcs-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Apr 2014 11:59:56 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Apr 2014 11:59:51 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Mon, 21 Apr 2014 11:59:47 -0700 From: ramki Krishnan To: "sfc@ietf.org" Date: Mon, 21 Apr 2014 11:59:46 -0700 Thread-Topic: New Version Notification for draft-krishnan-sfc-long-lived-flow-use-cases-02.txt Thread-Index: Ac9dk5RrkG9apiaQRoG1XZFs6jAaRwAAAieg Message-ID: References: <20140421185534.12667.84000.idtracker@ietfa.amsl.com> In-Reply-To: <20140421185534.12667.84000.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.96, 1.0.14, 0.0.0000 definitions=2014-04-21_03:2014-04-21,2014-04-21,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-1402240000 definitions=main-1404210284 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/aKHUh2adhvHovwA6dRARY-o2Rhk Cc: Anoop Ghanwani , "Joel M. Halpern" , Diego Lopez , Sriganesh Kini Subject: Re: [sfc] New Version Notification for draft-krishnan-sfc-long-lived-flow-use-cases-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, 21 Apr 2014 19:00:08 -0000 QWxsLA0KDQpXZSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aXRoIGFu IGFkZGl0aW9uYWwgTW9iaWxlIElQc2VjIHVzZSBjYXNlLiBZb3VyIGNvbW1lbnRzIGFyZSBhcHBy ZWNpYXRlZC4NCg0KVGhhbmtzLA0KUmFta2kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEFwcmlsIDIxLCAyMDE0IDExOjU2IEFNDQpUbzogU3Jp Z2FuZXNoIEtpbmk7IHJhbWtpIEtyaXNobmFuOyBKb2VsIEhhbHBlcm47IEpvZWwgTS4gSGFscGVy bjsgRGllZ28gUi4gTG9wZXo7IFNyaWdhbmVzaCBLaW5pOyBEaWVnbyBMb3BlejsgQW5vb3AgR2hh bndhbmk7IHJhbWtpIEtyaXNobmFuOyBBbm9vcCBHaGFud2FuaQ0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rcmlzaG5hbi1zZmMtbG9uZy1saXZlZC1mbG93LXVz ZS1jYXNlcy0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3Jpc2huYW4t c2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IHJhbSAocmFta2kpIGtyaXNobmFuIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWtyaXNobmFuLXNmYy1sb25nLWxpdmVkLWZs b3ctdXNlLWNhc2VzDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJU0ZDIExvbmctbGl2ZWQgRmxvdyBV c2UgQ2FzZXMNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDQtMjENCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta3Jpc2huYW4tc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2Ut Y2FzZXMtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQta3Jpc2huYW4tc2ZjLWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3Jpc2huYW4tc2Zj LWxvbmctbGl2ZWQtZmxvdy11c2UtY2FzZXMtMDINCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rcmlzaG5hbi1zZmMtbG9uZy1saXZlZC1mbG93 LXVzZS1jYXNlcy0wMg0KDQpBYnN0cmFjdDoNCiAgIExvbmctbGl2ZWQgZmxvd3Mgc3VjaCBhcyBm aWxlIHRyYW5zZmVycywgdmlkZW8gc3RyZWFtcyBhcmUgY29tbW9uIGluDQogICB0b2RheSdzIG5l dHdvcmtzLiBJbiB0aGUgY29udGV4dCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLCB0aGlz DQogICBkcmFmdCBzdWdnZXN0cyB1c2UgY2FzZXMgZm9yIGR5bmFtaWMgYnlwYXNzIG9mIGNlcnRh aW4gc2VydmljZSBub2Rlcw0KICAgZm9yIHN1Y2ggZmxvd3MuIFRoZSBiZW5lZml0IG9mIHRoaXMg YXBwcm9hY2ggd291bGQgYmUgdG8gYXZvaWQNCiAgIGV4cGVuc2l2ZSBMYXllciA3IHNlcnZpY2Ug bm9kZSBwcm9jZXNzaW5nIGZvciBzdWNoIGZsb3dzIGJhc2VkIG9uDQogICBkeW5hbWljIGRlY2lz aW9ucyBhbmQgaW1wcm92ZSBvdmVyYWxsIHBlcmZvcm1hbmNlLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Apr 21 13:00: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 EAEBC1A0277 for ; Mon, 21 Apr 2014 13:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 siuzUTf6qChP for ; Mon, 21 Apr 2014 13:00:01 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 31E0D1A0276 for ; Mon, 21 Apr 2014 13:00:01 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pn19so3556256lab.34 for ; Mon, 21 Apr 2014 12:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=LprlF+41FR1n45Xtf3ALMIZG3zg7QGMzJ/4FCoLSBWk=; b=MVYAR69BmcEUp9SYaS10Lf90h1pmXXYMW4eCPix5aDjRDmdOAGc4EZ4W26v0U4DLvp ZZ9MUyOlvF2VEyAXvgd3vK+rhj5qOj5sonuRPZgT8Cc9xk0g0/dkreySr9NjPzVjoaoZ Ss1BdukpvgOnNmO8iJxuIp8mQqNPBp1ayN5C3jhmD7rc5fxBqI85vz3Wp0dP8ibJN811 b3nBlafiBZ4qX9fCpstJWn1wH/sBMW3mjKQRjhKgEbivh6nSXeu9An0GX/pM18zIBsGb FSMmdpuTMoRHQ9PbUXlhklV4fpyVmbGzA2bZpocJIMWU2QyhMzbrVeEzCazdwPd/T2dV 3sYQ== MIME-Version: 1.0 X-Received: by 10.153.4.134 with SMTP id ce6mr28266815lad.21.1398110395438; Mon, 21 Apr 2014 12:59:55 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 21 Apr 2014 12:59:55 -0700 (PDT) In-Reply-To: <20140421195656.18585.39798.idtracker@ietfa.amsl.com> References: <20140421195656.18585.39798.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 14:59:55 -0500 Message-ID: From: Behcet Sarikaya To: sfc@ietf.org Content-Type: multipart/alternative; boundary=001a1134de967a1a3704f792f12f Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PNbNDXAVy5JYX4xrMLk_rJlxJkg Subject: [sfc] Fwd: New Version Notification for draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:00:03 -0000 --001a1134de967a1a3704f792f12f Content-Type: text/plain; charset=UTF-8 Hi all, We submitted this draft. It addresses an issue that is not covered in the use case and requirements drafts. We solicit that it should be. Regards, Behcet A new version of I-D, draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-xue-sfc-address-sharing-in-sfc-use-cases Revision: 00 Title: Host Identification Problem in Service Function Chaining Use Cases Document date: 2014-04-21 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt Status: https://datatracker.ietf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use-cases/ Htmlized: http://tools.ietf.org/html/draft-xue-sfc-address-sharing-in-sfc-use-cases-00 Abstract: The purpose of this document is to present host identification problem due to the address and prefix sharing in service function chaining. So far we have identified this problem in the two use cases of the parental control service and offloading service but it is likely that more use cases can be identified. 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 --001a1134de967a1a3704f792f12f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We submitted this= draft. It addresses an issue that is not covered in the use case and requi= rements drafts.
We solicit that it should be.

Regards= ,

Behcet



A new version of I-D, draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt=
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-xue-sfc-address-sharing-in-s= fc-use-cases
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Host Identification Problem in Ser= vice Function Chaining Use Cases
Document date: =C2=A02014-04-21
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-xue-sfc-address-s= haring-in-sfc-use-cases-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://datatracker.ietf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use-case= s/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools= .ietf.org/html/draft-xue-sfc-address-sharing-in-sfc-use-cases-00


Abstract:
=C2=A0 =C2=A0The purpose of this document is to present host identification=
=C2=A0 =C2=A0problem due to the address and prefix sharing in service funct= ion
=C2=A0 =C2=A0chaining. =C2=A0So far we have identified this problem in the = two use
=C2=A0 =C2=A0cases of the parental control service and offloading service b= ut it
=C2=A0 =C2=A0is likely that more use cases can be identified.




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.

The IETF Secretariat


--001a1134de967a1a3704f792f12f-- From nobody Mon Apr 21 13:00: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 D27E31A028A for ; Mon, 21 Apr 2014 13:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 lrtiRnHbjfHe for ; Mon, 21 Apr 2014 13:00:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 17A9E1A0277 for ; Mon, 21 Apr 2014 13:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4053; q=dns/txt; s=iport; t=1398110433; x=1399320033; h=from:to:subject:date:message-id:mime-version; bh=Pa9/+v6x75/Oktxm6IuL6XYGpheC6R8bI4oG/6hkUg0=; b=IVYdiW4IcUrsXTnR+uVP2GL+pRSQgwxCm6xYzOLysreCrqXjLa/YPMio 3GEWiRQw3QKPRL/MGjM7wy3nLU2B8eoaND0+6lmXvvfYqjEGUPIxKGAry YkU3YhEs2lxm2WY3uJ3BSQAWlxma2dUmWVMbRt9iyOXp/fpMaTgtsoo4V M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAEp4VVOtJV2b/2dsb2JhbABZgkJET1fEDoEjFnSCJQECBB1RHQEIBA0DAQIoORQJCgQBEgmIOA3OLheOUR6EMgSYbpJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,897,1389744000"; d="scan'208,217";a="319355610" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 21 Apr 2014 20:00:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3LK0Wsa032236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 20:00:32 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.127]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 15:00:32 -0500 From: "Jeffrey Napper (jenapper)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPXZxaU8UhsrhhTUWWEhfLxMVVkQ== Date: Mon, 21 Apr 2014 20:00:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.165.12] Content-Type: multipart/alternative; boundary="_000_CF7B458514703jenapperciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/J7BUkUXDqbwBIqMHLsuyRntfa-U Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 20:00:40 -0000 --_000_CF7B458514703jenapperciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support. From: "Jim Guichard (jguichar)" > Date: Saturday, April 19, 2014 at 12:31 AM To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF7B458514703jenapperciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.


From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Saturday, April 19, 2014 at 1= 2:31 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-kumar-sfc-dc-use-cases-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
 --_000_CF7B458514703jenapperciscocom_-- From nobody Mon Apr 21 13:13: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 D95A31A029F for ; Mon, 21 Apr 2014 13:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 aLEyzM7gm4V9 for ; Mon, 21 Apr 2014 13:13:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 179511A0277 for ; Mon, 21 Apr 2014 13:13:21 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s3LKD5D8019766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Apr 2014 15:13:10 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s3LKD5CX025047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 16:13:05 -0400 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.2]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 21 Apr 2014 16:13:05 -0400 From: "Muley, Praveen V (Praveen)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPXZxaU8UhsrhhTUWWEhfLxMVVkZscgOMQ Date: Mon, 21 Apr 2014 20:13:04 +0000 Message-ID: <22069265D1B36949926E9422EBF3B88173A64BD5@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: multipart/alternative; boundary="_000_22069265D1B36949926E9422EBF3B88173A64BD5US70TWXCHMBA10z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gvR6wn71RG3064hyfWPn4YdxCKA Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 21 Apr 2014 20:13:33 -0000 --_000_22069265D1B36949926E9422EBF3B88173A64BD5US70TWXCHMBA10z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: "Jim Guichard (jguichar)" > Date: Saturday, April 19, 2014 at 12:31 AM To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_22069265D1B36949926E9422EBF3B88173A64BD5US70TWXCHMBA10z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.<= /p>

 

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Saturday, April 19, 2014 at 12:31 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/draft-kuma= r-sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_22069265D1B36949926E9422EBF3B88173A64BD5US70TWXCHMBA10z_-- From nobody Mon Apr 21 13:14: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 00D3B1A0298 for ; Mon, 21 Apr 2014 13:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 eEpz7bvts-FD for ; Mon, 21 Apr 2014 13:14:07 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94C771A0277 for ; Mon, 21 Apr 2014 13:14:07 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s3LKE0ew020186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Apr 2014 15:14:01 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s3LKE0Cc004218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 16:14:00 -0400 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.2]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 21 Apr 2014 16:14:00 -0400 From: "Muley, Praveen V (Praveen)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPXYZLzdi3JeuUaEqhVtKwLHjnVpscgUVQ Date: Mon, 21 Apr 2014 20:13:57 +0000 Message-ID: <22069265D1B36949926E9422EBF3B88173A64BF0@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: multipart/alternative; boundary="_000_22069265D1B36949926E9422EBF3B88173A64BF0US70TWXCHMBA10z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dpb1MCfjiOdkwM8lEi4g5YhxgZs Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 20:14:10 -0000 --_000_22069265D1B36949926E9422EBF3B88173A64BF0US70TWXCHMBA10z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: "Jim Guichard (jguichar)" > Date: Saturday 19 April 2014 00:29 To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_22069265D1B36949926E9422EBF3B88173A64BF0US70TWXCHMBA10z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Saturday 19 April 2014 00:29
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/dr= aft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_22069265D1B36949926E9422EBF3B88173A64BF0US70TWXCHMBA10z_-- From nobody Mon Apr 21 13:25:13 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 4AD691A02A1 for ; Mon, 21 Apr 2014 13:25:11 -0700 (PDT) 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 mQdK5QKO6q1b for ; Mon, 21 Apr 2014 13:25:09 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id BDB941A02A0 for ; Mon, 21 Apr 2014 13:25:09 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id x10so4018345pdj.23 for ; Mon, 21 Apr 2014 13:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jLdX3voFQoWoBxpCdG/ENJsqKH81DAvwtfVfspEOlcA=; b=XMy84iziy7QVeDuJpPQSvHJ6r0JkV6zTjeH/wi5iVn8RkMTcJZdMY7PeCtvpdG/ojm 3oxFrL3Ww71Rt9E8us5lLOzwrLSX2NTJswVbv/QJdtT7QkxxzLz4c1fhjBmSDK8chGob W3kzOJqN6ocKW+4u/xoAcynpB1AM+us9anROUyztaRqAeqP8HmuyQKUd4uY7OnKYBNw4 HGFbYtsYmDcepSJMWIVLa+/GbjUiT5I3v8CkBDpH0f0pOkhB/3SNHMAHjnS0VruoqOui Rm3YHlbLmepq11c+LC2bgIV3bHdR+ylE08RjHqEN7nw3+cvRv2TOoSML8tzQro/rSY7z GsUw== X-Received: by 10.68.166.36 with SMTP id zd4mr40404061pbb.54.1398111904759; Mon, 21 Apr 2014 13:25:04 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id pv4sm79951091pbb.55.2014.04.21.13.25.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 13:25:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_31CAE80C-AEFF-40E5-A7F9-29CA1FD14283" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sam Aldrin In-Reply-To: Date: Mon, 21 Apr 2014 13:25:03 -0700 Message-Id: References: To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/r-MTTY7Ud_w1DS70_HEuDfiFe3A Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 20:25:11 -0000 --Apple-Mail=_31CAE80C-AEFF-40E5-A7F9-29CA1FD14283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Support!! On Apr 18, 2014, at 3:29 PM, Jim Guichard (jguichar) = wrote: > Dear WG: >=20 > This message begins a two week call for WG adoption of the document = http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt = ending 2nd May 2014.=20 >=20 > Please respond to the SFC mailing list with any statements of approval = or disapproval. >=20 > Please note: > This is not WG Last Call. The document is not final, and the WG is = expected to modify the document=92s content until there is WG consensus = that the content is solid. Therefore, please don=92t oppose adoption = just because you want to see changes to its content. > If you have objections to adoption of the document, please state your = reasons why, and explain what it would take to address your concerns. > If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them.=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_31CAE80C-AEFF-40E5-A7F9-29CA1FD14283 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Support!!

On Apr 18, = 2014, at 3:29 PM, Jim Guichard (jguichar) <jguichar@cisco.com> = wrote:

Dear WG:

This message begins a two week call for WG adoption of the = document http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt&n= bsp;ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of = approval or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is = expected to modify the document=92s content until there is WG consensus = that the content is solid. Therefore, please don=92t 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 them. 
_______________________________________________
sfc mailing = list
sfc@ietf.org
https://www.ietf.org/mail= man/listinfo/sfc

= --Apple-Mail=_31CAE80C-AEFF-40E5-A7F9-29CA1FD14283-- From nobody Mon Apr 21 15:03:36 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 D54AC1A02DC for ; Mon, 21 Apr 2014 15:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.172 X-Spam-Level: X-Spam-Status: No, score=-7.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 F6jBVwxvRd_Z for ; Mon, 21 Apr 2014 15:03:29 -0700 (PDT) Received: from mxebd06-public.idz.gs.com (mxe5.gs.com [199.99.47.101]) by ietfa.amsl.com (Postfix) with ESMTP id E79F31A02D1 for ; Mon, 21 Apr 2014 15:03:28 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,898,1389762000"; d="scan'208,217"; a="39036144" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxebd06.idz.gs.com with ESMTP; 21 Apr 2014 18:03:23 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp10ex.firmwide.corp.gs.com ([10.135.172.88]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 21 Apr 2014 18:03:23 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp10ex.firmwide.corp.gs.com ([10.135.172.88]) with mapi; Mon, 21 Apr 2014 18:03:22 -0400 To: "'Jim Guichard (jguichar)'" , "'sfc@ietf.org'" Date: Mon, 21 Apr 2014 18:03:20 -0400 Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpscnZNw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23070409A926GSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MbLcoDSaNXZ3M_WSqVaO_5tThWw Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 22:03:34 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A926GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the requirements listed in 3.1.2. Shouldn't we also call this out? * SFC solutions SHOULD not require any service functions to partici= pate in the implementation of SFCs. That is, service function nodes (LBs, proxys, FWs, etc.) need not understan= d anything about SFCs; they could just be performing as they are today. We = could have service functions that partake in SFC implementations but they d= on't need to be required to. Regards, From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: 18 April 2014 6:30 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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. Therefore, 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 y= our 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 issu= es and we can begin a dialog about how best to address them. --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A926GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like th= e requirements listed in 3.1.2.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Shouldn’= ;t we also call this out?

<= span style=3D'font-size:11.0pt;font-family:Symbol;color:#1F497D'>·=          SFC solutions SHOULD not require any service functions to parti= cipate in the implementation of SFCs.

 

That is= , service function nodes (LBs, proxys, FWs, etc.) need not understand anyth= ing about SFCs; they could just be performing as they are today. We could h= ave service functions that partake in SFC implementations but they don̵= 7;t need to be required to.

 

Regards,

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: sfc [mailto:sfc= -bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent:<= /b> 18 April 2014 6:30 PM
To: sfc@ietf.org
Subject: [sf= c] Call for adoption of draft-haeffner-sfc-use-case-mobility-01<= /span>

=  

D= ear WG:

 

This message begins a two week call for = WG adoption of the document http://www.ietf.org/id/draft-haeffner-= sfc-use-case-mobility-01.txt ending 2nd May 2014. =

=  

Please respond to the SFC mailing list with any statements= of approval or disapproval.

 

Please note:

1.<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp; This is not WG Last Call. The doc= ument is not final, and the WG is expected to modify the document’s c= ontent until there is WG consensus that the content is solid. Therefore, pl= ease don’t oppose adoption just because you want to see changes to it= s content.

2.   &n= bsp;   If you have objections= to adoption of the document, please state your reasons why, and explain wh= at it would take to address your concerns.

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

= --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A926GSCMAMP19EXfi_-- From nobody Mon Apr 21 15:22: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 94FBF1A02E6 for ; Mon, 21 Apr 2014 15:22:42 -0700 (PDT) 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 fj7sQVbj03Fw for ; Mon, 21 Apr 2014 15:22:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 37B041A02D3 for ; Mon, 21 Apr 2014 15:22:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4A54F1C0103; Mon, 21 Apr 2014 15:22:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 217BE1C0062; Mon, 21 Apr 2014 15:22:32 -0700 (PDT) Message-ID: <53559A24.4000208@joelhalpern.com> Date: Mon, 21 Apr 2014 18:22:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Zarny, Myo" , "'sfc@ietf.org'" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/okKLwjqVZlvUpqp5Br4jo_Ebq5I Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 22:22:44 -0000 I would prefer not to state that as a requirement. Where practical, we do indeed want (even need) to support existing service funciton implementations. But there will be some service functions which can not be proxied and which can not be placed into the middle of service chains. Trying to solve 100% of the cases, if possible at all, will likely dramatically slow the work down. Yours, Joel M. Halpern On 4/21/14, 6:03 PM, Zarny, Myo wrote: > I like the requirements listed in 3.1.2. > > Shouldn’t we also call this out? > > ·SFC solutions SHOULD not require any service functions to participate > in the implementation of SFCs. > > That is, service function nodes (LBs, proxys, FWs, etc.) need not > understand anything about SFCs; they could just be performing as they > are today. We could have service functions that partake in SFC > implementations but they don’t need to be required to. > > Regards, > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* 18 April 2014 6:30 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Call for adoption of > draft-haeffner-sfc-use-case-mobility-01 > > Dear WG: > > This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd > May 2014. > > Please respond to the SFC mailing list with any statements of approval > or disapproval. > > 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. Therefore, 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 them. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Apr 21 15:22: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 71A371A02D3 for ; Mon, 21 Apr 2014 15:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 9lIxwq5r0S0a for ; Mon, 21 Apr 2014 15:22:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 358221A02D1 for ; Mon, 21 Apr 2014 15:22:37 -0700 (PDT) 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 BFX34925; Mon, 21 Apr 2014 22:22:24 +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, 21 Apr 2014 23:21:48 +0100 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 23:22:23 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML702-CHM.china.huawei.com ([169.254.4.52]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 15:22:18 -0700 From: Cathy Zhang To: "Zarny, Myo" , "'Jim Guichard (jguichar)'" , "'sfc@ietf.org'" Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPXa2NTZIXbS+tbk23ana5itsdM5scolRw Date: Mon, 21 Apr 2014 22:22:18 +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.71] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F2A29FSJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oAGbj5YyNRNC5N5fHoYyR159ht4 Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 22:22:45 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F2A29FSJCEML703CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support this draft. Agree with Myo. I would like to suggest one more callout on "3.1.2. Requir= ements from use case" * SFC solutions SHOULD allow support traffic reclassification at an= y point of the chain (eg. due to any change of the n-tuple classification fields by a service fu= nction that does not understand the service chain header, or due to chain s= plit/forking etc.). Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Monday, April 21, 2014 3:03 PM To: 'Jim Guichard (jguichar)'; 'sfc@ietf.org' Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobilit= y-01 I like the requirements listed in 3.1.2. Shouldn't we also call this out? * SFC solutions SHOULD not require any service functions to partici= pate in the implementation of SFCs. That is, service function nodes (LBs, proxys, FWs, etc.) need not understan= d anything about SFCs; they could just be performing as they are today. We = could have service functions that partake in SFC implementations but they d= on't need to be required to. Regards, From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: 18 April 2014 6:30 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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. Therefore, 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 y= our 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 issu= es and we can begin a dialog about how best to address them. --_000_A2C96F6779E6A041BC7023CC207FC99418F2A29FSJCEML703CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support this draft.

 <= /p> 

Agree with Myo. I would like to suggest one=
 more callout on “3.1.2.  Req=
uirements from use case”

·      = ;   SFC solutions SHO= ULD allow support traffic reclassification at any point of the chain

(eg. due to any ch= ange of the n-tuple classification fields by a service function that does n= ot understand the service chain header, or due to chain split/forking etc.).

 <= /p>

Thanks,=

Cathy

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Monday, April 21, 2014 3:03 PM
To: 'Jim Guichard (jguichar)'; 'sfc@ietf.org'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-= mobility-01

 

I like the requirements l= isted in 3.1.2.

 <= /p>

Shouldn’t we also c= all this out?

·      = ;   SFC solutions SHO= ULD not require any service functions to participate in the implementation = of SFCs.

 <= /p>

That is, service function= nodes (LBs, proxys, FWs, etc.) need not understand anything about SFCs; th= ey could just be performing as they are today. We could have service functions that partake in SFC implementations but they don= 217;t need to be required to.

 <= /p>

Regards,

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: 18 April 2014 6:30 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

= Dear WG:

=  

= This message begins a two week call for WG adoption of the document http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt&nb= sp;ending 2nd May 2014. 

=  

= Please respond to the SFC mailing list with any statements of approval or d= isapproval.

=  

= Please note:

1.  &nb= sp;    This is not WG Last= Call. The document is not final, and the WG is expected to modify the docu= ment’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you w= ant to see changes to its content.

2.  &nb= sp;    If you have objecti= ons to adoption of the document, please state your reasons why, and explain= what it would take to address your concerns.

3.  &nb= sp;    If you have issues = with the content, by all means raise those issues and we can begin a dialog= about how best to address them. 

--_000_A2C96F6779E6A041BC7023CC207FC99418F2A29FSJCEML703CHMchi_-- From nobody Mon Apr 21 15:47: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 ED03E1A02DC for ; Mon, 21 Apr 2014 15:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.172 X-Spam-Level: X-Spam-Status: No, score=-7.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 3DL44hd6tpWX for ; Mon, 21 Apr 2014 15:47:00 -0700 (PDT) Received: from mxebdp04ex-public.idz.gs.com (mxe6.gs.com [207.17.33.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4C1A0067 for ; Mon, 21 Apr 2014 15:46:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,898,1389762000"; d="scan'208,217";a="119730542" Received: from unknown (HELO mxpbd01-public.ny.fw.gs.com) ([148.86.115.129]) by mxebdp04ex.idz.gs.com with ESMTP; 21 Apr 2014 18:46:53 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp12ex.firmwide.corp.gs.com ([10.135.172.21]) by mxpbd01.ny.fw.gs.com with ESMTP; 21 Apr 2014 18:46:53 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp12ex.firmwide.corp.gs.com ([10.135.172.21]) with mapi; Mon, 21 Apr 2014 18:46:53 -0400 To: "'Joel M. Halpern'" , "'sfc@ietf.org'" Date: Mon, 21 Apr 2014 18:46:52 -0400 Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: Ac9dsDSWiXHqoYpIRcu7DG1c0V6x1AAAF2vA Message-ID: References: <53559A24.4000208@joelhalpern.com> In-Reply-To: <53559A24.4000208@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23070409A934GSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PqJwfoRrXSZuETDbBEFEM7VI2ww Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 22:47:03 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A934GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel, Not sure about the comment about the need for proxying as a requirement for= SFC. Not all service functions are of proxying kind. Even load balancers d= on't have to proxy--DSR for example. Firewalls perform permit/deny; they do= n't proxy. Likewise with IDS/IPS. Etc. Etc. Shouldn't we assume that servic= e chains will consist of proxying and non-proxying kinds? Besides, I don't = read that the draft requires proxying, do you? I'm not saying service function nodes can't partake in SFC implementations-= no need to stifle innovation. But do we need to require that service functi= on nodes MUST understand SFC headers, for example? What happens to those th= at don't? Are they all legacy? For many users who have invested in non-SFC-= understanding equipment, that's practically a non-starter. And it will like= ly slow adoption, IMO. Regards, -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: 21 April 2014 6:22 PM To: Zarny, Myo [Tech]; 'sfc@ietf.org' Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobilit= y-01 I would prefer not to state that as a requirement. Where practical, we do indeed want (even need) to support existing service = funciton implementations. But there will be some service functions which can not be proxied and which= can not be placed into the middle of service chains. Trying to solve 100%= of the cases, if possible at all, will likely dramatically slow the work d= own. Yours, Joel M. Halpern On 4/21/14, 6:03 PM, Zarny, Myo wrote: > I like the requirements listed in 3.1.2. > > Shouldn't we also call this out? > > *SFC solutions SHOULD not require any service functions to participate > in the implementation of SFCs. > > That is, service function nodes (LBs, proxys, FWs, etc.) need not > understand anything about SFCs; they could just be performing as they > are today. We could have service functions that partake in SFC > implementations but they don't need to be required to. > > Regards, > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* 18 April 2014 6:30 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Call for adoption of > draft-haeffner-sfc-use-case-mobility-01 > > Dear WG: > > This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt > ending 2nd May 2014. > > Please respond to the SFC mailing list with any statements of approval > or disapproval. > > 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. Therefore, 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 them. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A934GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Joel,
 
Not sure about the comment about the need for = proxying as a requirement for SFC. Not all service functions are of proxyin= g kind. Even load balancers don't have to proxy--DSR for example. Firewalls= perform permit/deny; they don’t proxy. Likewise with IDS/IPS. Etc. Etc. Shouldn’t we assume that service cha= ins will consist of proxying and non-proxying kinds? Besides, I don’t= read that the draft requires proxying, do you?
 
I’m not saying service function nodes ca= n’t partake in SFC implementations—no need to stifle innovation= . But do we need to require that service function nodes MUST understand SFC= headers, for example? What happens to those that don’t? Are they all legacy? For many users who have invested in non-SFC-understand= ing equipment, that’s practically a non-starter. And it will likely s= low adoption, IMO.
 
Regards,
 
-----Original Message-----
From: Joel M. Halpern [mailto:jmh@jo= elhalpern.com]
Sent: 21 April 2014 6:22 PM
To: Zarny, Myo [Tech]; 'sfc@ietf.org'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobilit= y-01
 
I would prefer not to state that as a requirement.
Where practical, we do indeed want (even need) to support existing ser= vice funciton implementations.
But there will be some service functions which can not be proxied and = which can not be placed into the middle of service chains.  Trying to = solve 100% of the cases, if possible at all, will likely dramatically slow = the work down.
 
Yours,
Joel M. Halpern
 
On 4/21/14, 6:03 PM, Zarny, Myo wrote:
> I like the requirements listed in 3.1.2.
>
> Shouldn’t we also call this out?
>
> ·SFC solutions SHOULD not require any service functions to= participate
> in the implementation of SFCs.
>
> That is, service function nodes (LBs, proxys, FWs, etc.) need not=
> understand anything about SFCs; they could just be performing as = they
> are today. We could have service functions that partake in SFC
> implementations but they don’t need to be required to.
>
> Regards,
>
> *From:*sfc [mailto:sfc-bo= unces@ietf.org] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* 18 April 2014 6:30 PM
> *To:* sfc@ietf.org
> *Subject:* [sfc] Call for adoption of
> draft-haeffner-sfc-use-case-mobility-01
>
> Dear WG:
>
> This message begins a two week call for WG adoption of the docume= nt
> ending 2nd May 2014.
>
> Please respond to the SFC mailing list with any statements of app= roval
> or disapproval.
>
> 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. Therefore, please don’t oppose a= doption
> just because you want to see changes to its content.
>
> 2.If you have objections to adoption of the document, please stat= e
> 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 i= ssues
> and we can begin a dialog about how best to address them.
>
>
>
> _______________________________________________
> sfc mailing list
>
 
 --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A934GSCMAMP19EXfi_-- From nobody Mon Apr 21 16:36: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 98CED1A031D for ; Mon, 21 Apr 2014 16:36:46 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 jk7-AzGZUP0e for ; Mon, 21 Apr 2014 16:36:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 48E531A0319 for ; Mon, 21 Apr 2014 16:36:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 77B8E1C006D; Mon, 21 Apr 2014 16:36:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from localhost (adsl-108-129-132-243.aby.bellsouth.net [108.129.132.243]) by mailb2.tigertech.net (Postfix) with ESMTPA id 642691C006C; Mon, 21 Apr 2014 16:36:36 -0700 (PDT) Date: Mon, 21 Apr 2014 19:36:23 -0400 Message-ID: Importance: low From: "Jmh.direct" To: myo.zarny@gs.com, jmh@joelhalpern.com, sfc@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_285305343891184" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/u4894Va-WRwR-htv51Ru-GDxfkM Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 21 Apr 2014 23:36:46 -0000 ----_com.android.email_285305343891184 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2l0aG91dCBzb21lIGZpcm0gb2YgcHJveHkgYW55IGV4aXN0aW5nIGZ1bmN0aW9uIHdpbGwsIGlm IHVzZWQgaW4gc2ZjLCBsb3NlIHRnZSB0cmFuc3BvcnQgaGVhZGVyIGFuZCB0aGUgc2ZjIHNwZWNp ZmljIGhlYWRlci4KCllvdXJzLApKb2VsCgoKU2VudCBmcm9tIG15IFNhbXN1bmcgc21hcnRwaG9u ZSBvbiBBVCZUCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tClN1YmplY3Q6IFJF OiBbc2ZjXSBDYWxsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC1oYWVmZm5lci1zZmMtdXNlLWNhc2Ut bW9iaWxpdHktMDEgCkZyb206ICJaYXJueSwgTXlvIiA8TXlvLlphcm55QGdzLmNvbT4gClRvOiAi J0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4uY29tPiwiJ3NmY0BpZXRmLm9yZyci IDxzZmNAaWV0Zi5vcmc+IApDQzogIAoKSGkgSm9lbCwKwqAKTm90IHN1cmUgYWJvdXQgdGhlIGNv bW1lbnQgYWJvdXQgdGhlIG5lZWQgZm9yIHByb3h5aW5nIGFzIGEgcmVxdWlyZW1lbnQgZm9yIFNG Qy4gTm90IGFsbCBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgb2YgcHJveHlpbmcga2luZC4gRXZlbiBs b2FkIGJhbGFuY2VycyBkb24ndCBoYXZlIHRvIHByb3h5LS1EU1IgZm9yIGV4YW1wbGUuIEZpcmV3 YWxscyBwZXJmb3JtIHBlcm1pdC9kZW55OyB0aGV5IGRvbuKAmXQgcHJveHkuIExpa2V3aXNlIHdp dGggSURTL0lQUy4gRXRjLiBFdGMuIFNob3VsZG7igJl0IHdlIGFzc3VtZSB0aGF0IHNlcnZpY2Ug Y2hhaW5zIHdpbGwgY29uc2lzdCBvZiBwcm94eWluZyBhbmQgbm9uLXByb3h5aW5nIGtpbmRzPyBC ZXNpZGVzLCBJIGRvbuKAmXQgcmVhZCB0aGF0IHRoZSBkcmFmdCByZXF1aXJlcyBwcm94eWluZywg ZG8geW91PwrCoApJ4oCZbSBub3Qgc2F5aW5nIHNlcnZpY2UgZnVuY3Rpb24gbm9kZXMgY2Fu4oCZ dCBwYXJ0YWtlIGluIFNGQyBpbXBsZW1lbnRhdGlvbnPigJRubyBuZWVkIHRvIHN0aWZsZSBpbm5v dmF0aW9uLiBCdXQgZG8gd2UgbmVlZCB0byByZXF1aXJlIHRoYXQgc2VydmljZSBmdW5jdGlvbiBu b2RlcyBNVVNUIHVuZGVyc3RhbmQgU0ZDIGhlYWRlcnMsIGZvciBleGFtcGxlPyBXaGF0IGhhcHBl bnMgdG8gdGhvc2UgdGhhdCBkb27igJl0PyBBcmUgdGhleSBhbGwgbGVnYWN5PyBGb3IgbWFueSB1 c2VycyB3aG8gaGF2ZSBpbnZlc3RlZCBpbiBub24tU0ZDLXVuZGVyc3RhbmRpbmcgZXF1aXBtZW50 LCB0aGF04oCZcyBwcmFjdGljYWxseSBhIG5vbi1zdGFydGVyLiBBbmQgaXQgd2lsbCBsaWtlbHkg c2xvdyBhZG9wdGlvbiwgSU1PLgrCoApSZWdhcmRzLArCoAotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSAK U2VudDogMjEgQXByaWwgMjAxNCA2OjIyIFBNClRvOiBaYXJueSwgTXlvIFtUZWNoXTsgJ3NmY0Bp ZXRmLm9yZycKU3ViamVjdDogUmU6IFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWhh ZWZmbmVyLXNmYy11c2UtY2FzZS1tb2JpbGl0eS0wMQrCoApJIHdvdWxkIHByZWZlciBub3QgdG8g c3RhdGUgdGhhdCBhcyBhIHJlcXVpcmVtZW50LgpXaGVyZSBwcmFjdGljYWwsIHdlIGRvIGluZGVl ZCB3YW50IChldmVuIG5lZWQpIHRvIHN1cHBvcnQgZXhpc3Rpbmcgc2VydmljZSBmdW5jaXRvbiBp bXBsZW1lbnRhdGlvbnMuCkJ1dCB0aGVyZSB3aWxsIGJlIHNvbWUgc2VydmljZSBmdW5jdGlvbnMg d2hpY2ggY2FuIG5vdCBiZSBwcm94aWVkIGFuZCB3aGljaCBjYW4gbm90IGJlIHBsYWNlZCBpbnRv IHRoZSBtaWRkbGUgb2Ygc2VydmljZSBjaGFpbnMuwqAgVHJ5aW5nIHRvIHNvbHZlIDEwMCUgb2Yg dGhlIGNhc2VzLCBpZiBwb3NzaWJsZSBhdCBhbGwsIHdpbGwgbGlrZWx5IGRyYW1hdGljYWxseSBz bG93IHRoZSB3b3JrIGRvd24uCsKgCllvdXJzLApKb2VsIE0uIEhhbHBlcm4KwqAKT24gNC8yMS8x NCwgNjowMyBQTSwgWmFybnksIE15byB3cm90ZToKPiBJIGxpa2UgdGhlIHJlcXVpcmVtZW50cyBs aXN0ZWQgaW4gMy4xLjIuCj4KPiBTaG91bGRu4oCZdCB3ZSBhbHNvIGNhbGwgdGhpcyBvdXQ/Cj4K PiDCt1NGQyBzb2x1dGlvbnMgU0hPVUxEIG5vdCByZXF1aXJlIGFueSBzZXJ2aWNlIGZ1bmN0aW9u cyB0byBwYXJ0aWNpcGF0ZQo+IGluIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBTRkNzLgo+Cj4gVGhh dCBpcywgc2VydmljZSBmdW5jdGlvbiBub2RlcyAoTEJzLCBwcm94eXMsIEZXcywgZXRjLikgbmVl ZCBub3QKPiB1bmRlcnN0YW5kIGFueXRoaW5nIGFib3V0IFNGQ3M7IHRoZXkgY291bGQganVzdCBi ZSBwZXJmb3JtaW5nIGFzIHRoZXkKPiBhcmUgdG9kYXkuIFdlIGNvdWxkIGhhdmUgc2VydmljZSBm dW5jdGlvbnMgdGhhdCBwYXJ0YWtlIGluIFNGQwo+IGltcGxlbWVudGF0aW9ucyBidXQgdGhleSBk b27igJl0IG5lZWQgdG8gYmUgcmVxdWlyZWQgdG8uCj4KPiBSZWdhcmRzLAo+Cj4gKkZyb206KnNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKaW0gR3VpY2hh cmQKPiAoamd1aWNoYXIpCj4gKlNlbnQ6KiAxOCBBcHJpbCAyMDE0IDY6MzAgUE0KPiAqVG86KiBz ZmNAaWV0Zi5vcmcKPiAqU3ViamVjdDoqIFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mCj4gZHJh ZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmlsaXR5LTAxCj4KPiBEZWFyIFdHOgo+Cj4gVGhp cyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIHRoZSBk b2N1bWVudAo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1j YXNlLW1vYmlsaXR5LTAxLnR4dAo+IGVuZGluZyAybmQgTWF5IDIwMTQuCj4KPiBQbGVhc2UgcmVz cG9uZCB0byB0aGUgU0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIGFwcHJv dmFsCj4gb3IgZGlzYXBwcm92YWwuCj4KPiBQbGVhc2Ugbm90ZToKPgo+IDEuVGhpcyBpcyBub3Qg V0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMgbm90IGZpbmFsLCBhbmQgdGhlIFdHIGlzCj4g ZXhwZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1bWVudOKAmXMgY29udGVudCB1bnRpbCB0aGVyZSBp cyBXRyBjb25zZW5zdXMKPiB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBs ZWFzZSBkb27igJl0IG9wcG9zZSBhZG9wdGlvbgo+IGp1c3QgYmVjYXVzZSB5b3Ugd2FudCB0byBz ZWUgY2hhbmdlcyB0byBpdHMgY29udGVudC4KPgo+IDIuSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0 byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzdGF0ZQo+IHlvdXIgcmVhc29ucyB3 aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2Vy bnMuCj4KPiAzLklmIHlvdSBoYXZlIGlzc3VlcyB3aXRoIHRoZSBjb250ZW50LCBieSBhbGwgbWVh bnMgcmFpc2UgdGhvc2UgaXNzdWVzCj4gYW5kIHdlIGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91dCBo b3cgYmVzdCB0byBhZGRyZXNzIHRoZW0uCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBzZmMgbWFpbGluZyBsaXN0Cj4gc2ZjQGlldGYub3Jn Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPgrCoAo= ----_com.android.email_285305343891184 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5XaXRob3V0IHNvbWUgZmlybSBvZiBw cm94eSBhbnkgZXhpc3RpbmcgZnVuY3Rpb24gd2lsbCwgaWYgdXNlZCBpbiBzZmMsIGxvc2UgdGdl IHRyYW5zcG9ydCBoZWFkZXIgYW5kIHRoZSBzZmMgc3BlY2lmaWMgaGVhZGVyLjxkaXY+PGJyPjwv ZGl2PjxkaXY+WW91cnMsPC9kaXY+PGRpdj5Kb2VsPGJyPjxicj48YnI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4NyUiPlNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmYW1wO1Q8 L3NwYW4+IDwvZGl2Pjxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0t LS08YnI+U3ViamVjdDogUkU6IFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWhhZWZm bmVyLXNmYy11c2UtY2FzZS1tb2JpbGl0eS0wMSA8YnI+RnJvbTogIlphcm55LCBNeW8iICZsdDtN eW8uWmFybnlAZ3MuY29tJmd0OyA8YnI+VG86ICInSm9lbCBNLiBIYWxwZXJuJyIgJmx0O2ptaEBq b2VsaGFscGVybi5jb20mZ3Q7LCInc2ZjQGlldGYub3JnJyIgJmx0O3NmY0BpZXRmLm9yZyZndDsg PGJyPkNDOiAgPGJyPjxicj48YnI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc2l6 ZT0iMiI+CjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPkhpIEpvZWwsPC9mb250PjwvZGl2Pgo8 ZGl2Pjxmb250IGNvbG9yPSIjMUY0OTdEIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+CjxkaXY+PGZvbnQg Y29sb3I9IiMxRjQ5N0QiPk5vdCBzdXJlIGFib3V0IHRoZSBjb21tZW50IGFib3V0IHRoZSBuZWVk IGZvciBwcm94eWluZyBhcyBhIHJlcXVpcmVtZW50IGZvciBTRkMuIE5vdCBhbGwgc2VydmljZSBm dW5jdGlvbnMgYXJlIG9mIHByb3h5aW5nIGtpbmQuIEV2ZW4gbG9hZCBiYWxhbmNlcnMgZG9uJ3Qg aGF2ZSB0byBwcm94eS0tRFNSIGZvciBleGFtcGxlLiBGaXJld2FsbHMgcGVyZm9ybSBwZXJtaXQv ZGVueTsgdGhleSBkb27igJl0IHByb3h5LgpMaWtld2lzZSB3aXRoIElEUy9JUFMuIEV0Yy4gRXRj LiBTaG91bGRu4oCZdCB3ZSBhc3N1bWUgdGhhdCBzZXJ2aWNlIGNoYWlucyB3aWxsIGNvbnNpc3Qg b2YgcHJveHlpbmcgYW5kIG5vbi1wcm94eWluZyBraW5kcz8gQmVzaWRlcywgSSBkb27igJl0IHJl YWQgdGhhdCB0aGUgZHJhZnQgcmVxdWlyZXMgcHJveHlpbmcsIGRvIHlvdT88L2ZvbnQ+PC9kaXY+ CjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPiZuYnNwOzwvZm9udD48L2Rpdj4KPGRpdj48Zm9u dCBjb2xvcj0iIzFGNDk3RCI+SeKAmW0gbm90IHNheWluZyBzZXJ2aWNlIGZ1bmN0aW9uIG5vZGVz IGNhbuKAmXQgcGFydGFrZSBpbiBTRkMgaW1wbGVtZW50YXRpb25z4oCUbm8gbmVlZCB0byBzdGlm bGUgaW5ub3ZhdGlvbi4gQnV0IGRvIHdlIG5lZWQgdG8gcmVxdWlyZSB0aGF0IHNlcnZpY2UgZnVu Y3Rpb24gbm9kZXMgTVVTVCB1bmRlcnN0YW5kIFNGQyBoZWFkZXJzLCBmb3IgZXhhbXBsZT8gV2hh dCBoYXBwZW5zIHRvIHRob3NlIHRoYXQgZG9u4oCZdD8KQXJlIHRoZXkgYWxsIGxlZ2FjeT8gRm9y IG1hbnkgdXNlcnMgd2hvIGhhdmUgaW52ZXN0ZWQgaW4gbm9uLVNGQy11bmRlcnN0YW5kaW5nIGVx dWlwbWVudCwgdGhhdOKAmXMgcHJhY3RpY2FsbHkgYSBub24tc3RhcnRlci4gQW5kIGl0IHdpbGwg bGlrZWx5IHNsb3cgYWRvcHRpb24sIElNTy48L2ZvbnQ+PC9kaXY+CjxkaXY+PGZvbnQgY29sb3I9 IiMxRjQ5N0QiPiZuYnNwOzwvZm9udD48L2Rpdj4KPGRpdj48Zm9udCBjb2xvcj0iIzFGNDk3RCI+ UmVnYXJkcyw8L2ZvbnQ+PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+CgpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT5dCjxi cj4KClNlbnQ6IDIxIEFwcmlsIDIwMTQgNjoyMiBQTTxicj4KClRvOiBaYXJueSwgTXlvIFtUZWNo XTsgJ3NmY0BpZXRmLm9yZyc8YnI+CgpTdWJqZWN0OiBSZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRp b24gb2YgZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmlsaXR5LTAxPC9kaXY+CjxkaXY+ Jm5ic3A7PC9kaXY+CjxkaXY+SSB3b3VsZCBwcmVmZXIgbm90IHRvIHN0YXRlIHRoYXQgYXMgYSBy ZXF1aXJlbWVudC48L2Rpdj4KPGRpdj5XaGVyZSBwcmFjdGljYWwsIHdlIGRvIGluZGVlZCB3YW50 IChldmVuIG5lZWQpIHRvIHN1cHBvcnQgZXhpc3Rpbmcgc2VydmljZSBmdW5jaXRvbiBpbXBsZW1l bnRhdGlvbnMuPC9kaXY+CjxkaXY+QnV0IHRoZXJlIHdpbGwgYmUgc29tZSBzZXJ2aWNlIGZ1bmN0 aW9ucyB3aGljaCBjYW4gbm90IGJlIHByb3hpZWQgYW5kIHdoaWNoIGNhbiBub3QgYmUgcGxhY2Vk IGludG8gdGhlIG1pZGRsZSBvZiBzZXJ2aWNlIGNoYWlucy4mbmJzcDsgVHJ5aW5nIHRvIHNvbHZl IDEwMCUgb2YgdGhlIGNhc2VzLCBpZiBwb3NzaWJsZSBhdCBhbGwsIHdpbGwgbGlrZWx5IGRyYW1h dGljYWxseSBzbG93IHRoZSB3b3JrIGRvd24uPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+ WW91cnMsPC9kaXY+CjxkaXY+Sm9lbCBNLiBIYWxwZXJuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+ CjxkaXY+T24gNC8yMS8xNCwgNjowMyBQTSwgWmFybnksIE15byB3cm90ZTo8L2Rpdj4KPGRpdj4m Z3Q7IEkgbGlrZSB0aGUgcmVxdWlyZW1lbnRzIGxpc3RlZCBpbiAzLjEuMi48L2Rpdj4KPGRpdj4m Z3Q7PC9kaXY+CjxkaXY+Jmd0OyBTaG91bGRu4oCZdCB3ZSBhbHNvIGNhbGwgdGhpcyBvdXQ/PC9k aXY+CjxkaXY+Jmd0OzwvZGl2Pgo8ZGl2PiZndDsgwrdTRkMgc29sdXRpb25zIFNIT1VMRCBub3Qg cmVxdWlyZSBhbnkgc2VydmljZSBmdW5jdGlvbnMgdG8gcGFydGljaXBhdGUgPC9kaXY+CjxkaXY+ Jmd0OyBpbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgU0ZDcy48L2Rpdj4KPGRpdj4mZ3Q7PC9kaXY+ CjxkaXY+Jmd0OyBUaGF0IGlzLCBzZXJ2aWNlIGZ1bmN0aW9uIG5vZGVzIChMQnMsIHByb3h5cywg RldzLCBldGMuKSBuZWVkIG5vdCA8L2Rpdj4KPGRpdj4mZ3Q7IHVuZGVyc3RhbmQgYW55dGhpbmcg YWJvdXQgU0ZDczsgdGhleSBjb3VsZCBqdXN0IGJlIHBlcmZvcm1pbmcgYXMgdGhleSA8L2Rpdj4K PGRpdj4mZ3Q7IGFyZSB0b2RheS4gV2UgY291bGQgaGF2ZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0 IHBhcnRha2UgaW4gU0ZDIDwvZGl2Pgo8ZGl2PiZndDsgaW1wbGVtZW50YXRpb25zIGJ1dCB0aGV5 IGRvbuKAmXQgbmVlZCB0byBiZSByZXF1aXJlZCB0by48L2Rpdj4KPGRpdj4mZ3Q7PC9kaXY+Cjxk aXY+Jmd0OyBSZWdhcmRzLDwvZGl2Pgo8ZGl2PiZndDs8L2Rpdj4KPGRpdj4mZ3Q7ICpGcm9tOipz ZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gKk9uIEJlaGFsZiBPZiAqSmltIEd1aWNoYXJkPC9kaXY+CjxkaXY+ Jmd0OyAoamd1aWNoYXIpPC9kaXY+CjxkaXY+Jmd0OyAqU2VudDoqIDE4IEFwcmlsIDIwMTQgNjoz MCBQTTwvZGl2Pgo8ZGl2PiZndDsgKlRvOiogPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjwvZGl2Pgo8ZGl2PiZndDsgKlN1YmplY3Q6KiBbc2ZjXSBDYWxsIGZv ciBhZG9wdGlvbiBvZjwvZGl2Pgo8ZGl2PiZndDsgZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNl LW1vYmlsaXR5LTAxPC9kaXY+CjxkaXY+Jmd0OzwvZGl2Pgo8ZGl2PiZndDsgRGVhciBXRzo8L2Rp dj4KPGRpdj4mZ3Q7PC9kaXY+CjxkaXY+Jmd0OyBUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgdHdvIHdl ZWsgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50IDwvZGl2Pgo8ZGl2PiZndDsg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1oYWVmZm5lci1zZmMtdXNlLWNh c2UtbW9iaWxpdHktMDEudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWhhZWZmbmVy LXNmYy11c2UtY2FzZS1tb2JpbGl0eS0wMS50eHQ8L2E+IDwvZGl2Pgo8ZGl2PiZndDsgZW5kaW5n IDJuZCBNYXkgMjAxNC48L2Rpdj4KPGRpdj4mZ3Q7PC9kaXY+CjxkaXY+Jmd0OyBQbGVhc2UgcmVz cG9uZCB0byB0aGUgU0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIGFwcHJv dmFsIDwvZGl2Pgo8ZGl2PiZndDsgb3IgZGlzYXBwcm92YWwuPC9kaXY+CjxkaXY+Jmd0OzwvZGl2 Pgo8ZGl2PiZndDsgUGxlYXNlIG5vdGU6PC9kaXY+CjxkaXY+Jmd0OzwvZGl2Pgo8ZGl2PiZndDsg MS5UaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwuIFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWwsIGFu ZCB0aGUgV0cgaXMgPC9kaXY+CjxkaXY+Jmd0OyBleHBlY3RlZCB0byBtb2RpZnkgdGhlIGRvY3Vt ZW504oCZcyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyA8L2Rpdj4KPGRpdj4m Z3Q7IHRoYXQgdGhlIGNvbnRlbnQgaXMgc29saWQuIFRoZXJlZm9yZSwgcGxlYXNlIGRvbuKAmXQg b3Bwb3NlIGFkb3B0aW9uIDwvZGl2Pgo8ZGl2PiZndDsganVzdCBiZWNhdXNlIHlvdSB3YW50IHRv IHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50LjwvZGl2Pgo8ZGl2PiZndDs8L2Rpdj4KPGRpdj4m Z3Q7IDIuSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQs IHBsZWFzZSBzdGF0ZSA8L2Rpdj4KPGRpdj4mZ3Q7IHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBs YWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuPC9kaXY+Cjxk aXY+Jmd0OzwvZGl2Pgo8ZGl2PiZndDsgMy5JZiB5b3UgaGF2ZSBpc3N1ZXMgd2l0aCB0aGUgY29u dGVudCwgYnkgYWxsIG1lYW5zIHJhaXNlIHRob3NlIGlzc3VlcyA8L2Rpdj4KPGRpdj4mZ3Q7IGFu ZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3QgdG8gYWRkcmVzcyB0aGVtLjwv ZGl2Pgo8ZGl2PiZndDs8L2Rpdj4KPGRpdj4mZ3Q7PC9kaXY+CjxkaXY+Jmd0OzwvZGl2Pgo8ZGl2 PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rp dj4KPGRpdj4mZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8L2Rpdj4KPGRpdj4mZ3Q7IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48L2Rpdj4KPGRpdj4mZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48L2Rpdj4KPGRpdj4mZ3Q7PC9kaXY+ CjxkaXY+Jm5ic3A7PC9kaXY+CjwvZm9udD4KCgogPC9ib2R5Pg== ----_com.android.email_285305343891184-- From nobody Mon Apr 21 18:12: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 13A3B1A00FD; Mon, 21 Apr 2014 18:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.172 X-Spam-Level: X-Spam-Status: No, score=-4.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 ywS4MF81ZxNz; Mon, 21 Apr 2014 18:12:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8A821A0110; Mon, 21 Apr 2014 18:12:31 -0700 (PDT) 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 BDI61394; Tue, 22 Apr 2014 01:12:25 +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; Tue, 22 Apr 2014 02:11:47 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 02:12:23 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 09:12:17 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWwO2ZN9DNYdRwEi3MZ5fyWQNNpsbucIA//+jH4CAAXps8A== Date: Tue, 22 Apr 2014 01:12:17 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-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.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cS5SOU62gfOHkHGljMy1sLJTfV8 Cc: "spring@ietf.org" , "sfc@ietf.org" , Ron Parker Subject: [sfc] =?utf-8?b?562U5aSNOiAgV2h5IFRyYW5zcG9ydCBEZXBlbmRlbmNlIGlz?= =?utf-8?q?_deemed_as_a_problem=3F//re=3A_I-D_Action=3A_draft-ietf-sfc-pro?= =?utf-8?q?blem-statement-04=2Etxt?= 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, 22 Apr 2014 01:12:35 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQrlj5Hku7bkuro6IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1 a0BnbWFpbC5jb21dIOS7o+ihqCBSb2JlcnQgUmFzenVrDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ0 5pyIMjHml6UgMTg6MjkNCuaUtuS7tuS6ujogWHV4aWFvaHUNCuaKhOmAgTogUm9uIFBhcmtlcjsg c2ZjQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtzZmNdIFdoeSBUcmFu c3BvcnQgRGVwZW5kZW5jZSBpcyBkZWVtZWQgYXMgYSBwcm9ibGVtPy8vcmU6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KDQpIaSBYdSwNCg0KSG93 IHRvIHNpbXBseSB1c2UgdGhlIE1QTFMgbGFiZWwgc3RhY2sgdG8gcmVhbGl6ZSB0aGUgU0ZDIGhh cyBiZWVuIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1z cHJpbmctc2ZjLXVzZS1jYXNlLTAwLiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCuKAi1Ro ZSBkcmFmdCBzYXlzOuKAiw0KDQoidGhhdCBwYWNrZXQsIFNOMSBjb3VsZCBmdXJ0aGVyIGNvbnN1 bWUgdGhlIG1ldGFkYXRhIGNvbnRhaW5lZCBpbiB0aGUNCg0KTlNIIGFuZCBtZWFud2hpbGUgZGVj cmVhc2UgdGhlIHNlcnZpY2UgaW5kZXggdmFsdWUgd2l0aGluIHRoZSBOU0ggYnkNCg0KDQoNCm9u DQoNCuKAi2XigIsNCg0KDQoNCiLigIsNCg0KSSB3b3VsZCBvYnNlcnZlIGFmdGVyIHJlYWRpbmcg dGhpcyBkcmFmdCB0aGF0IFMNCuKAi3ggc2VydmljZSBub2RlIG1heSBub3QgYmUgY2FwYWJsZSBv ZiBoYW5kbGluZyBOU0ggb2YgYW55IHNvcnQgKGluY2x1ZGluZyBTUiBoZWFkZXIgLSBiZSBpdCBN UExTIGxhYmVsIHN0YWNrIG9yIElQdjYgRUhzKSB0aGVyZWZvciBtdWNoIG1vcmUgdGhlbiBqdXN0 IGRlY3JlYXNpbmcgdGhlIGluZGV4IHZhbHVlIGlzIHJlcXVpcmVkIGF0IFNOeC4NCg0K4oCLSXQg c2VlbXMgdGhhdCB0byByZWFsaXplIGFueSBzZXJ2aWNlIGNoYWluIHZpYSBtb3N0IG9mIHRvZGF5 J3Mgc2VydmljZSBub2RlcyBhIGZ1bGwgcmVtb3ZhbCBvZiBOU0ggYW5kIHJlLWFwcGxpY2F0aW9u IGlzIHJlcXVpcmVkIGF0IGRpcmVjdGx5IGF0dGFjaGVkIFNOcy4NCg0KW1hpYW9odV0gWW91ciBv YnNlcnZhdGlvbiBpcyBjb3JyZWN0LiBUaGUgU0YgcHJveHkgbXVzdCBzdHJpcCB0aGUgTlNIIGFu ZCB0aGUgU1IgaGVhZGVyIGJlZm9yZSBzZW5kaW5nIHRoZSBwYWNrZXRzIHRvIHRoZSBkaXJlY3Rs eSBhdHRhY2hlZCBsZWdhY3kgc2VydmljZSBmdW5jdGlvbnMuIFdoZW4gdGhlIHBhY2tldHMgd2Fz IHJldHVybmVkIGJ5IHNlcnZpY2UgZnVuY3Rpb25zLCB0aGUgU0YgcHJveHkgbXVzdCByZWltcG9z ZSB0aG9zZSBoZWFkZXJzIG9uIHRoZSBwYWNrZXRzLiBNZWFud2hpbGUsIHRoZSBTRiBwcm94eSBt dXN0IGRlY3JlYXNlIHRoZSBzZXJ2aWNlIGluZGV4IHZhbHVlIGJ5IDEuDQoNClRoYXQgYWN0dWFs bHkgbWVhbnMgdGhhdCBuZXR3b3JrIG5lZWRzIHRvIGNhcnJ5IHRoZSBzdGF0ZSBwcmV0dHkgbXVj aCBvdXQgb2YgYmFuZC4gU3VjaCBzdGF0ZSBjb3VsZCBiZSBjYXJyaWVkIHdpdGhpbiByb3V0aW5n IHByb3RvY29scyAodG9kYXkgQkdQIGlzIHVzZWQgZm9yIHRoYXQgaW4gTDNWUE4gY2FzZSkgb3Ig YnkgbmV3IG92ZXJsYXkgY29udHJvbCBwbGFuZSAtIHNhbWUgYXMgaXMgdXNlZCB0byBjYXJyeSB0 aGUgbWV0YWRhdGEuDQoNCltYaWFvaHVdIERpZCB5b3UgbWVhbiB0aGF0IHRoZSBtZXRhZGF0YSBz aG91bGQgYmUgdHJhbnNmZXJyZWQgdGhyb3VnaCB0aGUgY29udHJvbCBwbGFuZT8NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCkNoZWVycywNClIuDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_ 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 cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4gcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Sb2JlcnQgUmFzenVr PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bp l7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj40PC9zcGFuPuaciDxzcGFuIGxhbmc9 IkVOLVVTIj4yMTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE4OjI5PGJyPg0KPC9zcGFu PjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFh1eGlhb2h1PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsg c3ByaW5nQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbc2ZjXSBXaHkgVHJhbnNwb3J0IERl cGVuZGVuY2UgaXMgZGVlbWVkIGFzIGEgcHJvYmxlbT8vL3JlOiBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkhpIFh1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvdyB0byBzaW1wbHkgdXNlIHRoZSBNUExTIGxhYmVs IHN0YWNrIHRvIHJlYWxpemUgdGhlIFNGQyBoYXMgYmVlbiBkZXNjcmliZWQgaW4NCjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1zZmMtdXNlLWNhc2Ut MDAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1 LXNwcmluZy1zZmMtdXNlLWNhc2UtMDA8L2E+LiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgZHJhZnQgc2F5czo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPnRoYXQgcGFja2V0LCBTTjEgY291bGQgZnVydGhlciBjb25zdW1lIHRoZSBtZXRhZGF0YSBj b250YWluZWQgaW4gdGhlPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+TlNIIGFuZCBtZWFud2hpbGUgZGVjcmVhc2UgdGhlIHNlcnZpY2UgaW5kZXggdmFsdWUg d2l0aGluIHRoZSBOU0ggYnkmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPm9uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PuKAi2XigIs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+JnF1b3Q7 4oCLPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHdvdWxkIG9ic2VydmUgYWZ0ZXIg cmVhZGluZyB0aGlzIGRyYWZ0IHRoYXQgUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnggc2VydmljZSBub2RlIG1heSBub3QgYmUgY2FwYWJsZSBvZiBoYW5kbGluZyBOU0ggb2Yg YW55IHNvcnQgKGluY2x1ZGluZyBTUiBoZWFkZXIgLSBiZSBpdCBNUExTIGxhYmVsIHN0YWNrIG9y IElQdjYNCiBFSHMpIHRoZXJlZm9yIG11Y2ggbW9yZSB0aGVuIGp1c3QgZGVjcmVhc2luZyB0aGUg aW5kZXggdmFsdWUgaXMgcmVxdWlyZWQgYXQgU054LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FtYnJpYSBNYXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+SXQgc2VlbXMgdGhhdCB0byByZWFsaXplIGFueSBzZXJ2aWNlIGNoYWluIHZpYSBtb3N0 IG9mIHRvZGF5J3Mgc2VydmljZSBub2RlcyBhIGZ1bGwgcmVtb3ZhbCBvZiBOU0ggYW5kIHJlLWFw cGxpY2F0aW9uDQogaXMgcmVxdWlyZWQgYXQgZGlyZWN0bHkgYXR0YWNoZWQgU05zLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltYaWFvaHVdIFlvdXIgb2JzZXJ2YXRpb24gaXMg Y29ycmVjdC4gVGhlIFNGIHByb3h5IG11c3Qgc3RyaXAgdGhlIE5TSCBhbmQgdGhlIFNSIGhlYWRl ciBiZWZvcmUgc2VuZGluZyB0aGUgcGFja2V0cyB0byB0aGUgZGlyZWN0bHkgYXR0YWNoZWQgbGVn YWN5DQogc2VydmljZSBmdW5jdGlvbnMuIFdoZW4gdGhlIHBhY2tldHMgd2FzIHJldHVybmVkIGJ5 IHNlcnZpY2UgZnVuY3Rpb25zLCB0aGUgU0YgcHJveHkgbXVzdCByZWltcG9zZSB0aG9zZSBoZWFk ZXJzIG9uIHRoZSBwYWNrZXRzLiBNZWFud2hpbGUsIHRoZSBTRiBwcm94eSBtdXN0IGRlY3JlYXNl IHRoZSBzZXJ2aWNlIGluZGV4IHZhbHVlIGJ5IDEuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhdCBhY3R1YWxseSBtZWFucyB0aGF0IG5ldHdvcmsgbmVl ZHMgdG8gY2FycnkgdGhlIHN0YXRlIHByZXR0eSBtdWNoIG91dCBvZiBiYW5kLiBTdWNoIHN0YXRl IGNvdWxkIGJlIGNhcnJpZWQgd2l0aGluIHJvdXRpbmcgcHJvdG9jb2xzICh0b2RheSBCR1AgaXMg dXNlZCBmb3IgdGhhdCBpbiBMM1ZQTiBjYXNlKSBvciBieQ0KIG5ldyBvdmVybGF5IGNvbnRyb2wg cGxhbmUgLSBzYW1lIGFzIGlzIHVzZWQgdG8gY2FycnkgdGhlIG1ldGFkYXRhLiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWGlhb2h1XSBEaWQgeW91IG1lYW4gdGhhdCB0aGUg bWV0YWRhdGEgc2hvdWxkIGJlIHRyYW5zZmVycmVkIHRocm91Z2ggdGhlIGNvbnRyb2wgcGxhbmU/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhpYW9odTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q2hlZXJzLDxicj4NClIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9NKGEML512MBSchi_-- From nobody Mon Apr 21 22:52:25 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 C79071A008F for ; Mon, 21 Apr 2014 22:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 sM9KqGyrvDZt for ; Mon, 21 Apr 2014 22:52:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAC051A008A for ; Mon, 21 Apr 2014 22:52:18 -0700 (PDT) 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 BDI77100; Tue, 22 Apr 2014 05:52:12 +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, 22 Apr 2014 06:51:19 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 06:52:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 13:51:58 +0800 From: "Songhaibin (A)" To: Ron Parker , Xuxiaohu , "sfc@ietf.org" Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-00 Thread-Index: Ac9ZoN/oYzcTbeM+TgGZjuhgeN0QeQAOEnVQAMzZS6AAFH1PEAAj8CEw Date: Tue, 22 Apr 2014 05:51:57 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826BD18@NKGEML512-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.109] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F650BF25Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cObWtY4fB110VjuZbsa2E8fjYuo Subject: Re: [sfc] comments on draft-song-sfc-legacy-sf-mapping-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, 22 Apr 2014 05:52:24 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F650BF25Fnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQoNCkZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAyMSwgMjAxNCA4OjQ0IFBNDQpUbzog U29uZ2hhaWJpbiAoQSk7IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBjb21t ZW50cyBvbiBkcmFmdC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMA0KDQpQbGVhc2Ugc2Vl IGlubGluZSwgYmVsb3cuDQoNCiAgIFJvbg0KDQoNCkZyb206IFNvbmdoYWliaW4gKEEpIFttYWls dG86aGFpYmluLnNvbmdAaHVhd2VpLmNvbV0NClNlbnQ6IFN1bmRheSwgQXByaWwgMjAsIDIwMTQg MTE6MDYgUE0NClRvOiBYdXhpYW9odTsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogY29tbWVudHMgb24gZHJhZnQtc29uZy1zZmMtbGVn YWN5LXNmLW1hcHBpbmctMDANCg0KDQpIaSBSb24gYW5kIFhpYW9odSwNCg0KDQoNClRoYW5rIHlv dSBmb3IgdGhlIHdvbmRlcmZ1bCBjb21tZW50cy4NCg0KDQoNCldoYXQgYWJvdXQgdGhlIGZvbGxv d2luZyBjaGFuZ2VzICYgY2xhcmlmaWNhdGlvbnM/DQoNCg0KDQpUcmFuc3BhcmVudCBTRjogQSBz ZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZG9lcyBub3QgY2hhbmdlIGFueSBiaXQgb2YgdGhlIG9yaWdp bmFsIHNlcnZpY2UgcGFja2V0IGhlYWRlciBzZW50IHRvIGl0LCBuZWl0aGVyIGluamVjdCBhbnkg aW5kZXBlbmRlbnQgZmxvd3MgaW50byB0aGUgZGF0YSBzdHJlYW0uDQoNCg0KDQpSb24+PiBlZGl0 b3JpYWwgY29tbWVudCwgb25seSCoQyBjaGFuZ2UgobBuZWl0aGVyIGluamVjdKGxIHRvIKGwbm9y IHNoYWxsIGl0IGluamVjdKGxDQoNCg0KDQoNCg0KPlNlY3Rpb24gMy4xLjEuIExheWVyIDIgTUFD IEFkZHJlc3MNCg0KDQoNCipMZWdhY3kgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBvcGVyYXRlIGFi b3ZlIGxheWVyIDMgd291bGQgdHlwaWNhbGx5IG5vdCBiZSBhYmxlIHRvIHByZXNlcnZlIHRoZSBv cmlnaW5hbCBTTUFDLiAgIFRha2UgZm9yIGV4YW1wbGUgdGhlIEhUVFAgUHJveHksIGFnYWluLiAg IEEgdHlwaWNhbCBpbXBsZW1lbnRhdGlvbiBhY2NlcHRzIHNvY2tldHMgb24gdGhlIGNsaWVudC1m YWNpbmcgc2lkZSBhbmQgYmluZHMvY29ubmVjdHMgc29ja2V0cyBvbiB0aGUgc2VydmVyLWZhY2lu ZyBzaWRlLiAgIE91dGdvaW5nIHBhY2tldHMgYXJlIGVuY2Fwc3VsYXRlZCB3aXRoIGFuIEV0aGVy bmV0IGhlYWRlciBjb250YWluaW5nIHRoZSBsb2NhbCBNQUMgYWRkcmVzcyBhcyB0aGUgU01BQy4N Cg0KDQoNCkluIHRoaXMgZG9jLCB0aGUgSFRUUCBQcm94eSBpcyByZWdhcmRlZCBhcyB0aGUgbm9u LSB0cmFuc3BhcmVudCBTRi4gU28gdGhlIG1ldGhvZHMgZm9yIHRyYW5zcGFyZW50IFNGIGlzIG5v dCBhcHBsaWNhYmxlLg0KDQoNCg0KDQoNCj5TZWN0aW9uIDMuMS4yLiBWTEFODQoNCg0KDQoqVGhp cyBjb3VsZCBiZSBwcm9ibGVtYXRpYyBpbiBhIHZpcnR1YWxpemVkIGVudmlyb25tZW50IHdoZXJl IHRoZSBjb25uZWN0aW9uIGZyb20gdGhlIFNGSSB0byB0aGUgU0ZFIG1heSBub3QgYmUgYSBkaXJl Y3QgcGh5c2ljYWwgY29ubmVjdGlvbi4gICBBbiBTRE4tYmFzZWQgbmV0d29yayB0eXBpY2FsbHkg b3ducyB0aGUgVkxBTiBJRCBhbGxvY2F0aW9ucyBhbmQgaW50ZXJwcmV0YXRpb24uDQoNCg0KDQpU aGlzIG1ldGhvZCBpcyBhcHBsaWNhYmxlIGZvciB0cmFuc3BhcmVudCBTRiwgbWVhbndoaWxlLCB0 aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBTRkkgYW5kIFNGRSBpcyBpbiBhIEwyIG5ldHdvcmsu DQoNCg0KDQpSb24+PiBUaGF0IEwyIGNvbm5lY3Rpb24gYmV0d2VlbiBTRkkgYW5kIFNGRSBtYXkg YmUgZW11bGF0ZWQgdmlhIFNETi4gICBJbiB0aGlzIGNhc2UsIHRoYXQgd291bGQgbmVlZCB0byBi ZSBhIFZMQU4tdHJhbnNwYXJlbnQgRS1MaW5lLg0KDQoNCg0KW0hhaWJpbl0gWWVzLiBJIGFncmVl LiAgQWN0dWFsbHkgdGhlIGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgbGluZSBiZXR3ZWVuIFNGSSBh bmQgU0ZFIGRvZXMgbm90IGNoYW5nZSBhbnkgYml0IG9mIHRoZSBwYWNrZXQgb24gbGF5ZXIgMiBv ciB0aGUgYWJvdmUuIEluIHRoaXMgY2FzZSwgd2UgY2FuIHVzZSB0aGUgVkxBTiBmaWVsZCBvciBz b21lIG90aGVyIGZpZWxkcyBmb3IgdGhlIG1hcHBpbmcgYW5kIHJldHJpZXZhbCBvZiB0aGUgU0ZD IGhlYWRlci4NCg0KDQoNCkJSLA0KDQotSGFpYmluDQoNCg0KDQo+U2VjdGlvbiAzLjEuMy4gUWlu UQ0KDQoNCg0KKiBTYW1lIGNvbW1lbnQgYXMgZm9yIFZMQU4uDQoNCg0KDQoNCg0KVGhpcyBtZXRo b2QgaXMgYXBwbGljYWJsZSBmb3IgdHJhbnNwYXJlbnQgU0YsIG1lYW53aGlsZSwgdGhlIGNvbm5l Y3Rpb24gYmV0d2VlbiB0aGUgU0ZJIGFuZCBTRkUgaXMgaW4gYSBMMiBuZXR3b3JrLg0KDQoNCg0K DQoNCj5TZWN0aW9uIDMuMi4gIEZvciBOb24tdHJhbnNwYXJlbnQgU2VydmljZSBGdW5jdGlvbnMN Cg0KDQoNCiogVXNlIG9mIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIGF0IGEgcGFja2V0IG9yIGZs b3cgbGV2ZWwgd291bGQgYmUgZGlmZmljdWx0IHRvIHNjYWxlLg0KDQoNCg0KRm9yIG5vbi10cmFu c3BhcmVudCBTRiwgdHdvIG1ldGhvZHMgYXJlIGludHJvZHVjZWQgaW4gdGhlIGRvYywgb25lIGlz IHVzaW5nIDUtdHVwbGUgKGFwcGxpY2F0aW9uIGNvbmRpdGlvbjogNS10dXBsZSBvZiB0aGUgb3Jp Z2luYWwgcGFja2V0IHdpbGwgbm90IGJlIG1vZGlmaWVkIGJ5IHRoZSBsZWdhY3kgU0YpLiBUaGUg b3RoZXIgaXMgdXNpbmcgY29udHJvbCBwbGFuZSwgaS5lLiB0aGUgY29udHJvbCBwbGFuZSBwcm92 aWRlcyB0aGUgbWFwcGluZyBydWxlcy4gUGxlYXNlIHNlZSB0aGUgdGFibGUgZm9yIGRldGFpbHMu IEl0IHdvdWxkIGJlIGRpZmZpY3VsdCBwZXIgcGFja2V0IGxldmVsLCBidXQgZm9yIHBlciBmbG93 IGxldmVsLCBpdHMgY29tcGxleGl0eSBpcyBzaW1pbGFyIGFzIE5BVCBob3Qgc3RhbmRieS4NCg0K DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBUYWJsZSAxOiBPcGVyYXRpb24gQ29uc2lkZXJh dGlvbg0KDQoNCg0KDQorLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfE1ldGhvZHMgfElu Z3Jlc3MgRmxvdyAgICAgfEVncmVzcyBGbG93ICB8QXBwbGljYXRpb24gICAgICAgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHxNYXBwaW5nICAgICAgICAgIHxNYXBwaW5nICAgICAgfENvbmRpdGlv biAgICAgICAgICB8DQorLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfE1BQyAgICAgfDEu NS10dXBsZS0+U291cmNlfFNvdXJjZSBNQUMgICB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnxGb3Ig VHJhbnMtIHxBZGRyZXNzIHxNQUMgYWRkcmVzcyAgICAgIHxhZGRyZXNzLT5TRkMgfGJlIG1vZGlm aWVkIGJ5ICAgICB8DQp8cGFyZW50IFNGICB8ICAgICAgICB8Mi5BbnkgU0ZDICAgICAgICB8aGVh ZGVyICAgICAgIHx0aGUgU0ZJLiAgICAgICAgICAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfHBh Y2tldC0+U291cmNlICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHxNQUMgYWRkcmVzcyAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICB8DQp8ICAgICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfFZMQU4gICAgfDUt dHVwbGUtPlZMQU4gSUQgfFZMQU4gSUQtPlNGQyB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHxoZWFkZXIgICAgICAgfGJlIG1vZGlm aWVkIGJ5ICAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHx0aGUgU0ZJLiAgICAgICAgICAgfA0KfCAgICAgICAgICAgKy0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAg ICAgICAgIHxRaW5RICAgIHw1LXR1cGxlLT5PdXRlciAgIHxPdXRlciBWTEFOICAgfFRoZSBTRkkg aXMgcmVxdWlyZWR8DQp8ICAgICAgICAgICB8ICAgICAgICB8VkxBTiBJRCAgICAgICAgICB8SUQt PlNGQyAgICAgIHx0byBzdXBwb3J0IFFpblEuICAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgICAgICAgICAgfGhlYWRlciAgICAgICB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfGJlIG1vZGlm aWVkIGJ5ICAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHx0aGUgU0ZJLiAgICAgICAgICAgfA0KfCAgICAgICAgICAgKy0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAg ICAgICAgIHxWWExBTiAgIHw1LXR1cGxlLT5WTkkgICAgIHxWTkktPlNGQyAgICAgfFRoZSBTRkkg aXMgcmVxdWlyZWR8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8aGVh ZGVyICAgICAgIHx0byBzdXBwb3J0IFZYTEFOLiAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8TDIgaGVhZGVyIHdvbid0ICAgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfGJlIG1vZGlm aWVkIGJ5ICAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHx0aGUgU0ZJLiAgICAgICAgICAgfA0KKy0tLS0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAg ICAgICAgIHw1LXR1cGxlIHw1LXR1cGxlICAgICAgICAgIHw1LXR1cGxlICAgICAgfFRoZSA1LXR1 cGxlIG9mIHRoZSB8DQp8Rm9yICAgICAgICB8TWFwcGluZyB8LT41LXR1cGxlICAgICAgICB8LT5T RkMgaGVhZGVyIHxvcmlnaW5hbCBwYWNrZXQgICAgfA0KfE5vbi10cmFucy0gfCAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8d29uJ3QgYmUgbW9kaWZpZWQgIHwNCnxwYXJl bnQgU0YgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfGJ5IHRoZSBT RkkuICAgICAgICB8DQp8ICAgICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tKw0KfCAgICAgICAgICAgfENvbnRyb2wgfGUu Zy4gNS10dXBsZSAgICAgfGUuZy4gNS10dXBsZSd8VGhlIFNGRSBtdXN0IGJlICAgIHwNCnwgICAg ICAgICAgIHxQbGFuZSAgIHwtPjUtdHVwbGUnICAgICAgIHwtPlNGQyBoZWFkZXIgfGNvbmZpZ3Vy ZWQgb3IgYmUgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHxhYmxlIHRvIG9idGFpbiB0aGUgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8bWFwcGluZyBydWxlcyBvZiAgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfHRoZSBTRkku IFRoZSBTRkkgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHxvbmx5IGNoYW5nZXMgdGhlICAgfA0KfCAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8NS10dXBsZSBhY2NvcmRpbmcgIHwNCnwgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfHRvIHRoZSA1 LXR1cGxlICAgICB8DQp8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHxtYXBwaW5nIHJ1bGVzLiAgICAgfA0KKy0tLS0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoN Cg0KDQpCZXN0IFJlZ2FyZHMhDQoNCi1IYWliaW4NCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCg0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFh1eGlhb2h1DQoNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDk6 NDggQU0NCg0KPiBUbzogUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQoNCj4gU3ViamVjdDogW3NmY10gtPC4tDogY29tbWVudHMgb24gZHJhZnQtc29uZy1zZmMt bGVnYWN5LXNmLW1hcHBpbmctMDANCg0KPg0KDQo+DQoNCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cg0KPiA+ILeivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9u IFBhcmtlcg0KDQo+ID4gt6LLzcqxvOQ6IDIwMTTE6jTUwjE3yNUgMjozOA0KDQo+ID4gytW8/sjL OiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCg0KPiA+INb3zOI6IFtzZmNdIGNv bW1lbnRzIG9uIGRyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLTAwDQoNCj4gPg0KDQo+ ID4gVG8gdGhlIGF1dGhvcnMgb2YgZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmc6DQoN Cj4gPg0KDQo+ID4gVGhhbmsgeW91IGZvciBjb250cmlidXRpbmcgdGhpcyB3ZWxsIHdyaXR0ZW4g ZHJhZnQuICAgSSB0aGluayB0aGlzIGlzIGEgdmVyeQ0KDQo+ID4gd29ydGh3aGlsZSBpc3N1ZSB0 byB0YWNrbGUsIGJ1dCBkbyBoYXZlIHNvbWUgY29uY2VybnMgaW4gdGhlIGN1cnJlbnQgcmV2aXNp b24NCg0KPiBvZg0KDQo+ID4gdGhlIGRyYWZ0LiAgIE15IHNwZWNpZmljIGNvbW1lbnRzIGFyZSBi ZWxvdy4NCg0KPiA+DQoNCj4gPiBUaGFua3MuDQoNCj4gPg0KDQo+ID4gICAgIFJvbg0KDQo+ID4N Cg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IFNlY3Rpb24gMi4gVGVybWlub2xvZ3kNCg0KPiA+ DQoNCj4gPiAqIFN1Z2dlc3QgZW5oYW5jaW5nIHlvdXIgZGVmaW5pdGlvbiBvZiBUcmFuc3BhcmVu dCBTRiB0byBhbHNvIHN0YXRlIHRoYXQgaXQNCg0KPiBkb2VzDQoNCj4gPiBub3QgaW5qZWN0IGlu ZGVwZW5kZW50IGZsb3dzIGludG8gdGhlIGRhdGEgc3RyZWFtLiAgIEZvciBleGFtcGxlLCBzb21l DQoNCj4gPiB0cmFuc3BhcmVudCBIVFRQIFByb3hpZXMgYXJlIG5vdCBzb3VyY2UtaXAgdHJhbnNw YXJlbnQgZm9yIHNvbWUgb3IgYWxsDQoNCj4gPiBvZiB0aGVpciB1cHN0cmVhbSBjb25uZWN0aW9u cywgaW5zdGVhZCB1c2luZyB0aGVpciBvd24gbG9vcGJhY2sgb3INCg0KPiA+IGludGVyZmFjZSBJ UCBhZGRyZXNzZXMuDQoNCj4NCg0KPiBJIGFncmVlIHRoYXQgbm8gaW5qZWN0aW9uIG9mIGFkZGl0 aW9uYWwgZmxvd3Mgc2hvdWxkIGJlIGFub3RoZXIgcmVxdWlyZW1lbnQgZm9yDQoNCj4gdHJhbnNw YXJlbnQgU0YuIEhvd2V2ZXIsIEkgdGhpbmsgdGhlIHRyYW5zcGFyZW50IGxlZ2FjeSBTRiB3aGlj aCBpcyBhcHBsaWNhYmxlDQoNCj4gZm9yIHNlcnZpY2UgY2hhaW4gc2hvdWxkIGF0IGxlYXN0IG1l ZXQgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudDogbm8gY2hhbmdlIHRvDQoNCj4gdGhlIDUtdHVw bGUgb2YgdGhlIG9yaWdpbmFsIHBhY2tldC4gT3RoZXJ3aXNlLCBpdCB3b3VsZCBiZSB2ZXJ5IGhh cmQgb3IgZXZlbg0KDQo+IGltcG9zc2libGUgZm9yIHRoZSBTRkYgdG8gZG8gdGhlIG1hcHBpbmcg d2l0aG91dCB0aGUgYXNzaXN0YW5jZSBmcm9tIHRoZSBTRg0KDQo+IChlLmcuLCBwcm92aWRlIHRo ZSBtYXBwaW5ncyBjcmVhdGVkIG9uIHRoZSBTRiB0byB0aGUgU0ZGKS4gR2l2ZW4gdGhlIGFib3Zl DQoNCj4gcmVxdWlyZW1lbnQgaGFzIGJlZW4gbWV0LCB3aHkgbm90IGRpcmVjdGx5IHVzZSB0aGUg NS10dXBsZSBmb3IgdGhlIG1hcHBpbmcNCg0KPiBwdXJwb3NlPw0KDQo+DQoNCj4gQmVzdCByZWdh cmRzLA0KDQo+IFhpYW9odQ0KDQo+DQoNCj4gPiBTZWN0aW9uIDMuMS4xLiBMYXllciAyIE1BQyBB ZGRyZXNzDQoNCj4gPg0KDQo+ID4gKiBMZWdhY3kgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBvcGVy YXRlIGFib3ZlIGxheWVyIDMgd291bGQgdHlwaWNhbGx5IG5vdCBiZQ0KDQo+IGFibGUNCg0KPiA+ IHRvIHByZXNlcnZlIHRoZSBvcmlnaW5hbCBTTUFDLiAgIFRha2UgZm9yIGV4YW1wbGUgdGhlIEhU VFAgUHJveHksIGFnYWluLg0KDQo+IEENCg0KPiA+IHR5cGljYWwgaW1wbGVtZW50YXRpb24gYWNj ZXB0cyBzb2NrZXRzIG9uIHRoZSBjbGllbnQtZmFjaW5nIHNpZGUgYW5kDQoNCj4gPiBiaW5kcy9j b25uZWN0cyBzb2NrZXRzIG9uIHRoZSBzZXJ2ZXItZmFjaW5nIHNpZGUuICAgT3V0Z29pbmcgcGFj a2V0cyBhcmUNCg0KPiA+IGVuY2Fwc3VsYXRlZCB3aXRoIGFuIEV0aGVybmV0IGhlYWRlciBjb250 YWluaW5nIHRoZSBsb2NhbCBNQUMgYWRkcmVzcw0KDQo+ID4gYXMgdGhlIFNNQUMuDQoNCj4gPg0K DQo+ID4NCg0KPiA+DQoNCj4gPiBTZWN0aW9uIDMuMS4yLiBWTEFODQoNCj4gPg0KDQo+ID4gKiBU aGlzIGNvdWxkIGJlIHByb2JsZW1hdGljIGluIGEgdmlydHVhbGl6ZWQgZW52aXJvbm1lbnQgd2hl cmUgdGhlDQoNCj4gY29ubmVjdGlvbg0KDQo+ID4gZnJvbSB0aGUgU0ZJIHRvIHRoZSBTRkUgbWF5 IG5vdCBiZSBhIGRpcmVjdCBwaHlzaWNhbCBjb25uZWN0aW9uLiAgIEFuDQoNCj4gPiBTRE4tYmFz ZWQgbmV0d29yayB0eXBpY2FsbHkgb3ducyB0aGUgVkxBTiBJRCBhbGxvY2F0aW9ucyBhbmQNCg0K PiBpbnRlcnByZXRhdGlvbi4NCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IFNlY3Rpb24gMy4x LjMuIFFpblENCg0KPiA+DQoNCj4gPiAqIFNhbWUgY29tbWVudCBhcyBmb3IgVkxBTi4NCg0KPiA+ DQoNCj4gPg0KDQo+ID4NCg0KPiA+IFNlY3Rpb24gMy4yLiAgRm9yIE5vbi10cmFuc3BhcmVudCBT ZXJ2aWNlIEZ1bmN0aW9ucw0KDQo+ID4NCg0KPiA+ICogVXNlIG9mIGNvbnRyb2wgcGxhbmUgc2ln bmFsaW5nIGF0IGEgcGFja2V0IG9yIGZsb3cgbGV2ZWwgd291bGQgYmUNCg0KPiA+IGRpZmZpY3Vs dCB0byBzY2FsZS4NCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4gc2ZjIG1haWxpbmcg bGlzdA0KDQo+ID4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQoNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gc2ZjIG1haWxpbmcgbGlzdA0K DQo+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_E33E01DFD5BEA24B9F3F18671078951F650BF25Fnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ron,=

&n= bsp;

&n= bsp;

From: Ron Parker [= mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, April 21, 2014 8:44 PM
To: Songhaibin (A); Xuxiaohu; sfc@ietf.org
Subject: RE: comments on draft-song-sfc-legacy-sf-mapping-00

 

Please see inline, below.

 

   Ron

 

 

From: Songhaibin (A) [mailto:haibin.song@huawei.com]
Sent: Sunday, April 20, 2014 11:06 PM
To: Xuxiaohu; Ron Parker; sfc@ietf.o= rg
Subject: RE: comments on draft-song-sfc-legacy-sf-mapping-00

 

Hi Ron and Xiaohu,

 

Thank you for the wonderful = comments.

 

What about the following cha= nges & clarifications?

 

Transparent SF: A service fu= nction that does not change any bit of the original service packet header s= ent to it, neither inject any independent flows into the data stream.<= /o:p>

 

Ron>> editorial comment, only =A8C change =A1=B0neither = inject=A1=B1 to =A1=B0nor shall it inject=A1=B1

 

 

>Section 3.1.1. Layer 2 M= AC Address

 

*Legacy service functions th= at operate above layer 3 would typically not be able to preserve the origin= al SMAC.   Take for example the HTTP Proxy, again.   A = typical implementation accepts sockets on the client-facing side and binds/connects sockets on the server-facing side.   Out= going packets are encapsulated with an Ethernet header containing the local= MAC address as the SMAC.

 

In this doc, the HTTP Proxy = is regarded as the non- transparent SF. So the methods for transparent SF i= s not applicable.

 

 

>Section 3.1.2. VLAN=

 

*This could be problematic i= n a virtualized environment where the connection from the SFI to the SFE ma= y not be a direct physical connection.   An SDN-based network typ= ically owns the VLAN ID allocations and interpretation.

 

This method is applicable fo= r transparent SF, meanwhile, the connection between the SFI and SFE is in a= L2 network.

 

Ron>> That L2 connection between SFI and SFE may be emul= ated via SDN.   In this case, that would need to be a VLAN-transp= arent E-Line.

 

[Hai= bin] Yes. I agree.  Actually the assumption is that the line between S= FI and SFE does not change any bit of the packet on layer 2 or the above. I= n this case, we can use the VLAN field or some other fields for the mapping and retrieval of the SFC header.

 

BR,<= o:p>

-Hai= bin

 

>Section 3.1.3. QinQ=

 

* Same comment as for VLAN.<= o:p>

 

 

This method is applicable fo= r transparent SF, meanwhile, the connection between the SFI and SFE is in a= L2 network.

 

 

>Section 3.2.  For N= on-transparent Service Functions

 

* Use of control plane signa= ling at a packet or flow level would be difficult to scale.

 

For non-transparent SF, two = methods are introduced in the doc, one is using 5-tuple (application condit= ion: 5-tuple of the original packet will not be modified by the legacy SF).= The other is using control plane, i.e. the control plane provides the mapping rules. Please see the table for det= ails. It would be difficult per packet level, but for per flow level, its c= omplexity is similar as NAT hot standby.

 

 

    &nbs= p;            &= nbsp;   Table 1: Operation Consideration

 

 

+-----------+--------+-----------= ------+-------------+-------------------+

|       &n= bsp;   |Methods |Ingress Flow     |Egress Flo= w  |Application        |=

|       &n= bsp;   |        |Mapping =          |Mapping   =    |Condition        &nbs= p; |

+-----------+--------+-----------= ------+-------------+-------------------+

|       &n= bsp;   |MAC     |1.5-tuple->Source|Source = MAC   |L2 header won't    |

|For Trans- |Address |MAC address  =     |address->SFC |be modified by    = |

|parent SF  |    &nb= sp;   |2.Any SFC        |heade= r       |the SFI.    &nbs= p;      |

|       &n= bsp;   |        |packet->So= urce   |         &nb= sp;   |         &nbs= p;         |

|       &n= bsp;   |        |MAC address&n= bsp;     |       &nb= sp;     |       &nbs= p;           |=

|       &n= bsp;   +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |VLAN    |5-tuple->VLAN ID |VLAN ID->= SFC |L2 header won't    |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |header       |be modified by &= nbsp;   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI.         &nbs= p; |

|       &n= bsp;   +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |QinQ    |5-tuple->Outer   |Ou= ter VLAN   |The SFI is required|

|       &n= bsp;   |        |VLAN ID =          |ID->SFC  &nb= sp;   |to support QinQ.   |

|       &n= bsp;   |        |  &= nbsp;            &nb= sp; |header       |L2 header won't =    |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |be modified by     |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI.         &nbs= p; |

|       &n= bsp;   +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |VXLAN   |5-tuple->VNI    = ; |VNI->SFC     |The SFI is required|

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |header       |to support VXLAN.&nbs= p; |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |L2 header won't    |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |be modified by     |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI.         &nbs= p; |

+-----------+--------+-----------= ------+-------------+-------------------+

|       &n= bsp;   |5-tuple |5-tuple       = ;   |5-tuple      |The 5-tuple of the |<= o:p>

|For       = ; |Mapping |->5-tuple        |->SF= C header |original packet    |

|Non-trans- |     &n= bsp;  |          &nb= sp;      |      &nbs= p;      |won't be modified  |

|parent SF  |    &nb= sp;   |         &nbs= p;       |      = ;       |by the SFI.    &= nbsp;   |

|        &= nbsp;  +--------+-----------------+-------------+= -------------------+

|       &n= bsp;   |Control |e.g. 5-tuple     |e.g. 5-tup= le'|The SFE must be    |

|       &n= bsp;   |Plane   |->5-tuple'    &= nbsp;  |->SFC header |configured or be   |

|       &n= bsp;   |        |  &= nbsp;            &nb= sp; |           = ;  |able to obtain the |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |mapping rules of   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |the SFI. The SFI   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |only changes the   |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |5-tuple according  |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |to the 5-tuple     |

|       &n= bsp;   |        |  &= nbsp;           &nbs= p;  |           = ;  |mapping rules.     |

+-----------+--------+-----------= ------+-------------+-------------------+

 

 

Best Regards!

-Haibin

 

> -----Original Message--= ---

> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of X= uxiaohu

> Sent: Thursday, April 1= 7, 2014 9:48 AM

> To: Ron Parker; sfc@ietf.org

> Subject: [sfc] <= span style=3D"font-family:=CB=CE=CC=E5">=B4=F0=B8=B4: comments on draft-song-sfc-legacy-sf-mapping-00

>

>

> > -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> > =B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org= ] =B4=FA=B1=ED Ron Parker

> > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA<= span lang=3D"EN-US">4=D4=C2= 17=C8=D5 2:38

> > =CA=D5=BC=FE=C8=CB: sfc@ietf.org

> > =D6=F7=CC=E2: [sf= c] comments on draft-song-sfc-legacy-sf-mapping-00

> ><= /p>

> > To the authors of = draft-song-sfc-legacy-sf-mapping:

> ><= /p>

> > Thank you for cont= ributing this well written draft.   I think this is a very

> > worthwhile issue t= o tackle, but do have some concerns in the current revision

> of

> > the draft. &n= bsp; My specific comments are below.

> ><= /p>

> > Thanks.=

> ><= /p>

> >   &= nbsp; Ron

> ><= /p>

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 2. Termino= logy

> ><= /p>

> > * Suggest enhancin= g your definition of Transparent SF to also state that it=

> does<= /p>

> > not inject indepen= dent flows into the data stream.   For example, some

> > transparent HTTP P= roxies are not source-ip transparent for some or all

> > of their upstream = connections, instead using their own loopback or

> > interface IP addre= sses.

>

> I agree that no injecti= on of additional flows should be another requirement for<= /p>

> transparent SF. However= , I think the transparent legacy SF which is applicable

> for service chain shoul= d at least meet the following requirement: no change to

> the 5-tuple of the orig= inal packet. Otherwise, it would be very hard or even

> impossible for the SFF = to do the mapping without the assistance from the SF

> (e.g., provide the mapp= ings created on the SF to the SFF). Given the above

> requirement has been me= t, why not directly use the 5-tuple for the mapping

> purpose?

>

> Best regards,

> Xiaohu

>

> > Section 3.1.1. Lay= er 2 MAC Address

> ><= /p>

> > * Legacy service f= unctions that operate above layer 3 would typically not be

> able<= /p>

> > to preserve the or= iginal SMAC.   Take for example the HTTP Proxy, again.=

> A

> > typical implementa= tion accepts sockets on the client-facing side and

> > binds/connects soc= kets on the server-facing side.   Outgoing packets are=

> > encapsulated with = an Ethernet header containing the local MAC address

> > as the SMAC.<= /o:p>

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 3.1.2. VLA= N

> ><= /p>

> > * This could be pr= oblematic in a virtualized environment where the

> connection

> > from the SFI to th= e SFE may not be a direct physical connection.   An

> > SDN-based network = typically owns the VLAN ID allocations and

> interpretation.

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 3.1.3. Qin= Q

> ><= /p>

> > * Same comment as = for VLAN.

> ><= /p>

> ><= /p>

> ><= /p>

> > Section 3.2. = For Non-transparent Service Functions

> ><= /p>

> > * Use of control p= lane signaling at a packet or flow level would be

> > difficult to scale= .

> ><= /p>

> ><= /p>

> ><= /p>

> ><= /p>

> > __________________= _____________________________

> > 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_E33E01DFD5BEA24B9F3F18671078951F650BF25Fnkgeml501mbschi_-- From nobody Mon Apr 21 23:42: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 03C811A00BE for ; Mon, 21 Apr 2014 23:42:08 -0700 (PDT) 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 nNKLROy_qVdS for ; Mon, 21 Apr 2014 23:42:04 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AE00C1A00BC for ; Mon, 21 Apr 2014 23:42:03 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d17so4202464eek.1 for ; Mon, 21 Apr 2014 23:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Gvn0u3vHv7BUXe+7wk+P1xFFU1u1N3gx7bHgUHKV+o=; b=QrC036/QVfOawcCcCFvJ8O+rAyrFtLEP0ytyY4ZtjjYnGaWXzqnUe5RaWP0q2Adn8z 82BhqNfUdrWFcCvhAqXE5IIsWfzixZL5xZt/JHtmk6fhbst35x72KsXV2sN1k0UOz0gQ tPisJ5YX1mKo7j8lbd9DaPSIMhz+6jjw9vOrQ4ct9JhPQGfT4WcsL58R5WS50umtsdy7 Px2EaSYLZCpwqAC16jXrmAnfiZcOYmex8MXWUljhxWiYhjG66IrSbOqVQGzDjVh4QhHS yfcJWVaI02VeT8zqTXtvNbjBc9ZB4crDzc9QvzMqwUqiPW9fcSSuu6LKjQqpCROSAxQj hlZA== X-Received: by 10.15.10.3 with SMTP id f3mr53034957eet.1.1398148918001; Mon, 21 Apr 2014 23:41:58 -0700 (PDT) Received: from [192.168.2.106] (p4FCF782F.dip0.t-ipconnect.de. [79.207.120.47]) by mx.google.com with ESMTPSA id x45sm110111365eeu.23.2014.04.21.23.41.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 23:41:57 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Martin Stiemerling In-Reply-To: Date: Tue, 22 Apr 2014 08:41:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <581EAA0A-3BCB-494F-A624-F0C17B3DAA27@gmail.com> References: To: "Zarny, Myo" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/G3_iQAZMWODQKCjmLFoKq9yr158 Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 22 Apr 2014 06:42:08 -0000 Hi,=20 Am 22.04.2014 um 00:03 schrieb Zarny, Myo : > I like the requirements listed in 3.1.2. > =20 > Shouldn=92t we also call this out? > =B7 SFC solutions SHOULD not require any service functions to = participate in the implementation of SFCs. Isn=92t this a bit too strong? I assume you are coming from the legacy = side, i.e., existing functions should be able to include in SFCs. = However, this statement says that no function should be required to = changed in order to participate in SFCs. Or what does it mean? Martin > =20 > That is, service function nodes (LBs, proxys, FWs, etc.) need not = understand anything about SFCs; they could just be performing as they = are today. We could have service functions that partake in SFC = implementations but they don=92t need to be required to. > =20 > Regards, > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar) > Sent: 18 April 2014 6:30 PM > To: sfc@ietf.org > Subject: [sfc] Call for adoption of = draft-haeffner-sfc-use-case-mobility-01 > =20 > Dear WG: > =20 > This message begins a two week call for WG adoption of the document = http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt = ending 2nd May 2014.=20 > =20 > Please respond to the SFC mailing list with any statements of approval = or disapproval. > =20 > Please note: > 1. This is not WG Last Call. The document is not final, and the = WG is expected to modify the document=92s content until there is WG = consensus that the content is solid. Therefore, please don=92t 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 them.=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 21 23:49: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 43AC11A00D1 for ; Mon, 21 Apr 2014 23:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 zLDp_AYV2A-J for ; Mon, 21 Apr 2014 23:48:55 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 719D41A00BF for ; Mon, 21 Apr 2014 23:48:54 -0700 (PDT) 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 <0N4F00G6Z6X81X@tid.hi.inet> for sfc@ietf.org; Tue, 22 Apr 2014 08:48:44 +0200 (MEST) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id C0.E8.03703.CC016535; Tue, 22 Apr 2014 08:48:44 +0200 (CEST) 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 <0N4F00G6T6X81X@tid.hi.inet> for sfc@ietf.org; Tue, 22 Apr 2014 08:48:44 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.62]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 08:48:44 +0200 Date: Tue, 22 Apr 2014 06:48:59 +0000 From: "Diego R. Lopez" In-reply-to: <581EAA0A-3BCB-494F-A624-F0C17B3DAA27@gmail.com> X-Originating-IP: [10.95.64.115] To: Martin Stiemerling Message-id: <17B07080-6CF0-49A2-9770-C8A8BB542791@tid.es> Content-id: <597E1F50BEF8D841A26564AC200EB435@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-index: AQHPXfX8AOPSq8hgAk+U/Es2OhguNpsdEFYA X-AuditID: 0a5f4068-f79636d000000e77-be-535610ccd9d4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsXCFe/ApXtGICzYYM1DCYsnD7ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9vK3YwFzyUrvu69xdjA+Eyki5GTQ0LAROLTnW1sELaYxIV7 68FsIYGDjBIPTmt1MXIB2d8YJU6+72CDcKYxSpzZtRTI4eBgEVCVWH8iHaSBDch81PybHcQW FvCXaPvwnBnE5hSwlXhzrRlqgYLEn3OPWUBsEQFtidefPoPVMAuUSLS2/QWr4RWwlPix9Qgj RNxMYnvzRai4oMSPyfdYIOJ6Eh//3IaqEZdobr0JFdeWePLuAiuIzSggK/Fu/nxWiF0BEjtf dzKBnCwiYCRxdYcGxDkCEkv2nGeGsEUlXj7+xwrx+yZGiRf3DCcwSsxCcsUsJFfMQnLFLCRX zEJyxQJG1lWMYsVJRZnpGSW5iZk56QaGehmZepl5qSWbGCExl7GDcflOlUOMAhyMSjy8ERmh wUKsiWXFlbmHGCU4mJVEeNP/AIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzxr0uChASSE8sSc1O TS1ILYLJMnFwSjUwpoap7TttLzTv9iXRb0vmND27cvHDttx0r5ezdKwteNRK3FJ503b2xdlW hqY8cxG9mvtPmu2xafN++dlqR9ncm0tMGzV5n3+4F8R20XnPTovWqV6vsuq53jjFTJn4itn/ 3BGDq1uCF7xQ7vuoKRi/936ejYfJW6Zvfz5KfTHbniPO6bTz7et2JZbijERDLeai4kQAfxoj LLUCAAA= References: <581EAA0A-3BCB-494F-A624-F0C17B3DAA27@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EjukwTm2nOxHrDU552MgsUWl8XU Cc: "Jim Guichard \(jguichar\)" , "Zarny, Myo" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 22 Apr 2014 06:48:59 -0000 Hi, As far as I understand, it says that SFC implementations should be complete= ly oblivious to the processing performed by the service functions, and shou= ld not rely on them to actually implement chaining and paths. It simplifies= the way for legacy functions being integrated in a SFC framework, Be goode, On 22 Apr 2014, at 08:41 , Martin Stiemerling wrote: > Hi, > Am 22.04.2014 um 00:03 schrieb Zarny, Myo : > >> I like the requirements listed in 3.1.2. >> >> Shouldn=92t we also call this out? >> =B7 SFC solutions SHOULD not require any service functions to pa= rticipate in the implementation of SFCs. > > Isn=92t this a bit too strong? I assume you are coming from the legacy si= de, i.e., existing functions should be able to include in SFCs. However, th= is statement says that no function should be required to changed in order t= o participate in SFCs. > > Or what does it mean? > > Martin > >> >> That is, service function nodes (LBs, proxys, FWs, etc.) need not unders= tand anything about SFCs; they could just be performing as they are today. = We could have service functions that partake in SFC implementations but the= y don=92t need to be required to. >> >> Regards, >> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguic= har) >> Sent: 18 April 2014 6:30 PM >> To: sfc@ietf.org >> Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility= -01 >> >> Dear WG: >> >> This message begins a two week call for WG adoption of the document http= ://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd M= ay 2014. >> >> Please respond to the SFC mailing list with any statements of approval o= r disapproval. >> >> Please note: >> 1. This is not WG Last Call. The document is not final, and the WG= is expected to modify the document=92s content until there is WG consensus= that the content is solid. Therefore, please don=92t oppose adoption just = because you want to see changes to its content. >> 2. If you have objections to adoption of the document, please stat= e 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 i= ssues and we can begin a dialog about how best to address them. >> _______________________________________________ >> 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From nobody Tue Apr 22 00:28: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 1A4F61A010F; Tue, 22 Apr 2014 00:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 G1W9vuILyR_L; Tue, 22 Apr 2014 00:28:12 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 057B11A010E; Tue, 22 Apr 2014 00:28:11 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so4848797ier.41 for ; Tue, 22 Apr 2014 00:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=D8GfO5K7MjKf1NRiBJauqim/fZq2BJMcWLdhzV8dPdM=; b=Lx3no+bYH4CU/qvuPiimQfMBIo9SkoGk2+TFRsZV+dLnLLB1Q8qNZfH4poILtqJKtj O207FXFVJ9UBD19tiEOvTfV4D2ATbyEmx/FiT9qws6jeyHuMjSx2PBPEu5EpBFEctJxS adBcSmgL1p6rDrZGJJe2rVd5kxgQolIQGY6rdQgdQJLZVQM9fBJD5KmFbtpMPgYbXErC 6zrVs2kk3GKpSB5BJjpSSsTmevNGkahU4md4twOPSjtPJbV/j/1QUs9L1+kPWuJqbN0D tVVw4mLhNjx0QYSlSyKTcmwBx2Zn8lmdIhb97qX+ncrysL9qk5K9nI07M3mBtSErzNYw oikA== MIME-Version: 1.0 X-Received: by 10.50.82.73 with SMTP id g9mr27813055igy.0.1398151686729; Tue, 22 Apr 2014 00:28:06 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Tue, 22 Apr 2014 00:28:06 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> Date: Tue, 22 Apr 2014 09:28:06 +0200 X-Google-Sender-Auth: NDmCc_I7BkpOze3cKHhrwMhmosg Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/J4CJQIm11cRjk0r7w_HVZewkeEM Cc: "spring@ietf.org" , Ron Parker , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBXaHkgVHJhbnNwb3J0IERlcGVuZGVuY2UgaXMg?= =?utf-8?q?deemed_as_a_problem=3F//re=3A_I-D_Action=3A_draft-ietf-sfc-prob?= =?utf-8?q?lem-statement-04=2Etxt?= 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, 22 Apr 2014 07:28:13 -0000 > [Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the SR header before sending the packets to the directly attached legacy service functions. When the packets was returned by service functions, the SF proxy must reimpose those headers on the packets. Meanwhile, the SF proxy must decrease the service index value by 1. > Good so we agree on that point. What actually worries me a bit that to "reimpose" you need to do full classification again - just like you do it on all ingress nodes. Moreover how you reimpose could be also a function of service product. > > That actually means that network needs to carry the state pretty much out of band. Such state could be carried within routing protocols (today BGP is used for that in L3VPN case) or by new overlay control plane - same as is used to carry the metadata. > > > [Xiaohu] Did you mean that the metadata should be transferred through the control plane? How else would you carry it ? It's not data plane after all. Of course perhaps your definition of control plane = routing protocols, but I did not mean that. Control plane is just a information overlay of some form. Just like IN networks in well known telephone networks :) Cheers, R. From nobody Tue Apr 22 00:31: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 347421A0125 for ; Tue, 22 Apr 2014 00:31:18 -0700 (PDT) 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] 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 yfU8yjAPeZ7Z for ; Tue, 22 Apr 2014 00:31:15 -0700 (PDT) Received: from mc34.lon.server.colt.net (mc34.lon.server.colt.net [212.74.77.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0717F1A0053 for ; Tue, 22 Apr 2014 00:31:15 -0700 (PDT) Received: from mc34.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7F41C1A80AA for ; Tue, 22 Apr 2014 07:30:38 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc34.lon.server.colt.net (Postfix) with ESMTP id 5DAA01A80A9 for ; Tue, 22 Apr 2014 07:30:38 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,902,1389740400"; d="scan'208,217";a="979181" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 22 Apr 2014 09:30:37 +0200 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([10.12.1.3]) with mapi id 14.01.0438.000; Tue, 22 Apr 2014 09:30:38 +0200 From: Nicolas BOUTHORS To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1rL8RYkC0hXKUyjvDyAk3Zo5psdQrHI Date: Tue, 22 Apr 2014 07:30:37 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D43CDD0@LILAS.jungle.qosmos.com> References: In-Reply-To: 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_76B41B8FACE1514795D30EC137FF391D43CDD0LILASjungleqosmos_" MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1017-20648.005 X-TM-AS-Result: No--10.339-5.0-31-10 X-imss-scan-details: No--10.339-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1017-20648.005 X-TMASE-Result: 10--10.338800-5.000000 X-TMASE-MatchedRID: UuaOI1zLN1hfsB4HYR80Zm/CU2X9JBM7a/fioJ9l4Hiyd65qZFFPk1YW wxB9tw0TkE4SFWFFa6kXIJWO/t2WjtUW1/ttV+ezrA6HcPclJMaAfODDLypXmv0QRisLa4YzgZR 8lUh/my/4Pj9zynK9+jwLILmNaFe87sOH2+VDrlXqK9Dyg7qdQiGZtiDVlw6eWltirZ/iPP4rn9 Wz1CYUsA1qiBJ7H03Vjnb+xh4N4+I2mb97H0+8sMG0UNgaZpYqGsvgUMYAn4UKmNzCCRlbzlHXx CnNdK1Od372uppnAbWod3Te/uSXAfWfKuqzviIeQesjq8XPMbussAu2h3oDpqr1EweP157QeUQN vU47zujMo94uWO7d28+FUkWI6u1TFh5HIElqLTyeAiCmPx4NwGmRqNBHmBve3TrdyO4a2u21VfZ rX9mxWOiWSRQoTk/4p/fIcFGrubfvFONXC+v+ZXMoX+aJlbpHN35xYUMvrQ/8lrykQppjEnuCxa YSyFZLSp75gXAJd3bFQ+EfYYQz4A== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AvHsmS9KTWWR-_rLhhafpd8285Y Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 22 Apr 2014 07:31:18 -0000 --_000_76B41B8FACE1514795D30EC137FF391D43CDD0LILASjungleqosmos_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the adoption of http://www.ietf.org/id/draft-kumar-sfc-dc-use-ca= ses-01.txt Nicolas Bouthors ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Saturday, April 19, 2014 12:31 AM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_76B41B8FACE1514795D30EC137FF391D43CDD0LILASjungleqosmos_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
= I support the adoption of  http://www.ietf.org/id/draft-= kumar-sfc-dc-use-cases-01.txt 

Nicolas Bouthors
From: Jim Guichard (jguichar) [jguichar@c= isco.com]
Sent: Saturday, April 19, 2014 12:31 AM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= br>
Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt=  ending 2nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
--_000_76B41B8FACE1514795D30EC137FF391D43CDD0LILASjungleqosmos_-- From nobody Tue Apr 22 01:58: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 07B1B1A0183 for ; Tue, 22 Apr 2014 01:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 tKNZwwTH7ftT for ; Tue, 22 Apr 2014 01:58:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A83331A0187 for ; Tue, 22 Apr 2014 01:58:20 -0700 (PDT) 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 BDI96369; Tue, 22 Apr 2014 08:58:14 +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; Tue, 22 Apr 2014 09:57:33 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 09:58:09 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.62]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 16:58:01 +0800 From: "Hongyu Li (Julio)" To: Lucy yong , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of SFC use case documents Thread-Index: AQHPW1K8K2mTLR48uE+GohTdExdCc5sX9OdggAVYz0A= Date: Tue, 22 Apr 2014 08:58:00 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9F312A@SZXEMA509-MBX.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@dfweml701-chm.china.huawei.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_6EB34CB5D82C4645B826C56144826EA97E9F312ASZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UASYorJQ_1_-bE7zlSKJ6yRiPg0 Subject: Re: [sfc] Progression of SFC use case documents 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, 22 Apr 2014 08:58:26 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97E9F312ASZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hhaXJzLA0KDQpJIHN1cHBvcnQgTHVjeeKAmXMgY29tbWVudC4gZHJhZnQta3VtYXItc2Zj LWRjLXVzZS1jYXNlIGhhcyBhIGZhbmN5IG5hbWUsIGJ1dCBub3Qgc28gZmFuY3kgdXNlIGNhc2Vz LiBTbmlwcGVkIGZyb20gQ2hhaXJz4oCZIGVtYWlsOg0KMS4gICAgICAgQWRvcHQgYSBzbWFsbCBu dW1iZXIgb2YgV0cgZG9jdW1lbnRzIChpbml0aWFsbHkgMikgdGhhdCBhcmUgYXBwbGljYWJsZSB0 byBzcGVjaWZpYyBlbnZpcm9ubWVudHMgYW5kIHRoYXQgY2FuIGJlIHdvcmtlZCBvbiBpbmRlcGVu ZGVudGx5IGJ5IG1lbWJlcnMgb2YgdGhlIFdHIHRoYXQgaGF2ZSB0aGUgbmVjZXNzYXJ5IGV4cGVy dGlzZSBmb3IgdGhhdCBlbnZpcm9ubWVudCwNCkJvdGggbW9iaWxlIGFuZCBmaXhlZCBuZXR3b3Jr IG1heSBwdXQgdGhlaXIgU2VydmljZSBGdW5jdGlvbnMgaW4gYSB2aXJ0dWFsIGVudmlyb25tZW50 LCB3aGljaCBpcyB2ZXJ5IHBvc3NpYmx5ICBhIGRhdGFjZW50ZXIuIFNvLCBkcmFmdC1rdW1hci1z ZmMtZGMtdXNlLWNhc2UgaGFzIGEgZ3JlYXQgb3ZlcmxhcCB3aXRoIG90aGVyIHVzZSBjYXNlIGRy YWZ0cyBpbmNsdWRpbmcsIGV2ZW4gdGhvdWdoIHlvdSB3YW50IHRvIGhhdmUg4oCcc3BlY2lmaWMg ZW52aXJvbm1lbnRz4oCdIGFuZCBjbGVhbiBjdXRzIGJldHdlZW4gdGhlbS4NCmFuZCB0aGF0IGNh biB3b3JrIGRpcmVjdGx5IHdpdGggdGhlIGFwcGxpY2FibGUgU0RPcyBvbiBpbmNvcnBvcmF0aW5n IHJlbGV2YW50IGNvbnRlbnQuDQpUaGVyZSB3YXMgYSBxdWVzdGlvbiBvbiB0aGUgbWFpbGluZyBs aXN0IGFza2luZyB3aGF0IGFyZSB0aGUgU0RPcyBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2Ug aXMgY29ycmVzcG9uZGluZyB0bywgYnV0IG5vIGFuc3dlciB3YXMgcG9zdGVkIHNvIGZhci4NCg0K U28sIGl0IHNlZW1zIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZSBkb2VzbuKAmXQgc2VydmUg eW91ciBwdXJwb3NlIGF0IGFsbC4NCg0KQlIsDQpIb25neXUNCg0KRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWN5IHlvbmcNClNlbnQ6IFNhdHVy ZGF5LCBBcHJpbCAxOSwgMjAxNCA3OjA2IEFNDQpUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7 IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFByb2dyZXNzaW9uIG9mIFNGQyB1c2Ug Y2FzZSBkb2N1bWVudHMNCg0KRGVhciBDaGFpcnMsDQoNClBlb3BsZSBpbmNsdWRpbmcgbXlzZWxm IGRpZCBub3Qgdm9pY2UgYSBzaW5nbGUgZG9jdW1lbnQgdG8gY2FwdHVyZSBhbGwgcG9zc2libGUg dXNlIGNhc2VzIGJlY2F1c2UgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyB0aGF0LiBXZSBzdWdnZXN0 ZWQgY2FwdHVyaW5nIGFsbCBuZWNlc3NhcnkgdXNlIGNhc2VzIHRoYXQgaGVscCBkcml2aW5nIHRo ZSBhcmNoaXRlY3R1cmUgYW5kIHJlcXVpcmVtZW50IGRldmVsb3BtZW50Lg0KDQpHaXZpbmcgdGhl IHNpdHVhdGlvbiwgSSBzdXBwb3J0IGFkb3B0aW5nIGRyYWZ0LWhhZWZmbmVyLXNmYy11c2UtY2Fz ZS1tb2JsaXR5IGFzIFdHIGRyYWZ0LiBUaGlzIGlzIGJlY2F1c2UgYSBsYXJnZSBwb3J0aW9uIG9m IFNGQyB1c2UgY2FzZXMgYXJlIGluIE1vYmlsZSBhcHBsaWNhdGlvbnM7IGFuZCB0aGUgZHJhZnQg ZGVzY3JpYmVzIG1hbnkgdW5pcXVlIHdheXMgdG8gdXNlIFNGQy4gSXQgaXMgZ29vZCB0byBoYXZl IG9uZSBkcmFmdCB0byBjb3ZlciBNb2JpbGUgYXJlYS4NCg0KSU1POiBkcmFmdC1rdW1hci1zZmMt ZGMtdXNlLWNhc2VzIGRvZXMgbm90IGRlcGljdCB1bmlxdWUgU0ZDIGNhc2VzIGZyb20gYSBnZW5l cmFsIFNGQyBjYXNlIGV4Y2VwdCB0aGUgU0ZDIGFwcGxpY2F0aW9ucyBsb2NhdGlvbiBpcyBpbiBk YXRhIGNlbnRlcnMuIFRodXMgdGhlc2UgY2FzZXMgY2FuIGJlIGVhc2lseSBtZXJnZWQgaW50byB0 aGUgZ2VuZXJhbCB1c2UgY2FzZSBkcmFmdC4gU28gd2UgaGF2ZSBhbm90aGVyIHVzZSBjYXNlIGRy YWZ0IGZvciB0aGUgcmVzdC4NCg0KUmVnYXJkcywNCkx1Y3kNCg0KRGVhciBXRzoNCg0KVGhlcmUg aGFzIGJlZW4gbXVjaCBkaXNjdXNzaW9uIGJvdGggb24gdGhlIGxpc3QgYW5kIGR1cmluZyBvdXIg ZmFjZS10by1mYWNlIG1lZXRpbmdzIGFib3V0IGhvdyBiZXN0IHRvIHByb2dyZXNzIHVzZSBjYXNl IGRvY3VtZW50cyB3aXRoaW4gdGhlIFdHLiBUaGVyZSBhcmUgY2xlYXJseSBhcmd1bWVudHMgZm9y IGJvdGggb2YgdGhlIGZvbGxvd2luZyBhcHByb2FjaGVzOg0KDQogIDEuICBBIHNpbmdsZSBkb2N1 bWVudCB0aGF0IGNhcHR1cmVzIGFsbCBvZiB0aGUgcG9zc2libGUgdXNlIGNhc2VzLg0KICAyLiAg QSBzbWFsbCBudW1iZXIgb2YgdGFyZ2V0ZWQgZG9jdW1lbnRzIHRoYXQgYXJlIGZvY3VzZWQgb24g YSBwYXJ0aWN1bGFyIHN1YnNldCBvZiB0aGUgb3ZlcmFsbCBwcm9ibGVtIHNwYWNlIChzdWNoIGFz IGJyb2FkYmFuZCwgbW9iaWxpdHksIGFuZCBkYXRhIGNlbnRlcikuDQpCdXQsIHdlIGNhbuKAmXQg Y2hvb3NlIGJvdGguIEluIGNvbnNpZGVyaW5nIHRoZXNlIGFwcHJvYWNoZXMsIHRoZSBjaGFpcnMg cmVjb2duaXplIHRoYXQgdGhlcmUgYXJlIGJlbmVmaXRzIHRvIGhhdmluZyBhIHNpbmdsZSBkb2N1 bWVudCwgYnV0IGRvIG5vdCBiZWxpZXZlIGhhdmluZyBqdXN0IG9uZSBkb2N1bWVudCBpcyB3b3Jr YWJsZSBpbiB0aGlzIGNhc2UuIE5vciBpcyB0aGVyZSBjb25zZW5zdXMgZm9yIGhhdmluZyBhIHNp bmdsZSBkb2N1bWVudC4gIFRoZXJlZm9yZSwgd2Ugd2lsbCBwdXJzdWUgdGhlIGZvbGxvd2luZyBh cHByb2FjaCBnb2luZyBmb3J3YXJkOg0KDQogIDEuICBBZG9wdCBhIHNtYWxsIG51bWJlciBvZiBX RyBkb2N1bWVudHMgKGluaXRpYWxseSAyKSB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIHNwZWNpZmlj IGVudmlyb25tZW50cyBhbmQgdGhhdCBjYW4gYmUgd29ya2VkIG9uIGluZGVwZW5kZW50bHkgYnkg bWVtYmVycyBvZiB0aGUgV0cgdGhhdCBoYXZlIHRoZSBuZWNlc3NhcnkgZXhwZXJ0aXNlIGZvciB0 aGF0IGVudmlyb25tZW50LCBhbmQgdGhhdCBjYW4gd29yayBkaXJlY3RseSB3aXRoIHRoZSBhcHBs aWNhYmxlIFNET3Mgb24gaW5jb3Jwb3JhdGluZyByZWxldmFudCBjb250ZW50Lg0KICAyLiAgQ29u dGludWUgdG8gbGVhdmUgb3BlbiB0aGUgcG9zc2liaWxpdHkgb2YgYWRvcHRpbmcgYSBoaWdoLWxl dmVsIHVzZSBjYXNlIGRvY3VtZW50IHRoYXQgc2VydmVzIGFzIGEg4oCcY2F0Y2ggYWxs4oCdIGZv ciB1c2UgY2FzZXMgdGhhdCBkbyBub3QgbWVyaXQgdGhlaXIgb3duIGRvY3VtZW50IG9yIGFyZSBu b3QgY2FwdHVyZWQgaW4gdGhlIGNvbnRlbnQgb2YgbW9yZSBmb2N1c2VkIHVzZSBjYXNlIGRvY3Vt ZW50cy4gSG93ZXZlciwgYmVmb3JlIHRha2luZyBvbiBzdWNoIGEgZG9jdW1lbnQsIHRoZSBXRyB3 aWxsIG5lZWQgdG8gdW5kZXJzdGFuZCBpbiBtb3JlIGRldGFpbCB3aGF0IHRoZSBjb250ZW50IHdv dWxkIGJlIGFuZCB0aGF0IHRoZSBjb250ZW50IGp1c3RpZmllcyBoYXZpbmcgc3VjaCBhIGRvY3Vt ZW50LiBTdWNoIGEgZG9jdW1lbnQgc2hvdWxkIG5vdCBkdXBsaWNhdGUgbWF0ZXJpYWwgdGhhdCBp cyBjb3ZlcmVkIGluIG90aGVyIGRvY3VtZW50cy4NClRvIGZhY2lsaXRhdGUgdGhlIGFib3ZlIGRp cmVjdGlvbiB0aGUgY2hhaXJzIHdpbGwgdGFrZSB0aGUgZm9sbG93aW5nIHN0ZXBzOg0KDQogIDEu ICBDYWxsIGZvciB0aGUgYWRvcHRpb24gb2YgZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1v YmxpdHkgYW5kIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZXMgYXMgV0cgZG9jdW1lbnRzLg0K ICAyLiAgRW5jb3VyYWdlIHRoZSBhdXRob3JzIHRvIGNvbnRpbnVlIHRvIHdvcmsgb24gcmVmaW5l bWVudCBvZiBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy4gVGhlIGF1dGhvcnMgb2YgdGhhdCBkb2N1 bWVudCBzaG91bGQgdXBkYXRlIHRoZWlyIGRyYWZ0IHRvIHJlbW92ZSBhbnkgZHVwbGljYXRpb24g b2YgbWF0ZXJpYWwgY292ZXJlZCBpbiBvdGhlciBkb2N1bWVudHMgYXMgd2VsbCBhcyBpZGVudGlm eSBjb250ZW50IHRoYXQgaXMgbm90IGNvdmVyZWQgZWxzZXdoZXJlLg0KV2UgaG9wZSB0aGF0IHRo aXMgYXBwcm9hY2ggd2lsbCBhbGxvdyB0aGUgV0cgdG8gbW92ZSBmb3J3YXJkIGFuZCBhbHNvIHBy b3ZpZGUgZW5vdWdoIGZsZXhpYmlsaXR5IHRvIGFsbG93IHVzZSBjYXNlcyB0byBldm9sdmUgaW5k ZXBlbmRlbnRseSwgd2l0aCBkaXJlY3QgaW50ZXJhY3Rpb24gd2l0aCB0aGUgYXBwcm9wcmlhdGUg U0RPcy4NCg0KVGhhbmtzLA0KDQpKaW0gJiBUaG9tYXMNCg== --_000_6EB34CB5D82C4645B826C56144826EA97E9F312ASZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MjIwNDg2MjQ2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUz MjE3MDU5Mjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDozNjAzMjUxNjI7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjYzNjI0NjA3Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcy LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6Mzc3MzE3NjIyOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo5NjYxMTAxNjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxl dmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6NjQxMjI3Mjg5Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMjA4NDY1NzQ5ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxl dmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTM0MzQzODI1NjsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTE0MTQ1MjI5OTg7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTQyNjE0NTY3 MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMTcxMTQ5NDt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBDaGFpcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgc3VwcG9ydCBMdWN54oCZcyBjb21tZW50LiBkcmFmdC1r dW1hci1zZmMtZGMtdXNlLWNhc2UgaGFzIGEgZmFuY3kgbmFtZSwgYnV0IG5vdCBzbyBmYW5jeSB1 c2UgY2FzZXMuIFNuaXBwZWQgZnJvbSBDaGFpcnPigJkgZW1haWw6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM1LjdwdDt0ZXh0LWluZGVudDotMTcuODVwdDttc28tbGlzdDpsMiBsZXZl bDEgbGZvNjtsYXlvdXQtZ3JpZC1tb2RlOmNoYXIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFkb3B0IGEgc21hbGwgbnVtYmVyIG9mIFdH IGRvY3VtZW50cyAoaW5pdGlhbGx5IDIpIHRoYXQgYXJlIGFwcGxpY2FibGUgdG8gc3BlY2lmaWMg ZW52aXJvbm1lbnRzIGFuZCB0aGF0IGNhbiBiZSB3b3JrZWQgb24gaW5kZXBlbmRlbnRseQ0KIGJ5 IG1lbWJlcnMgb2YgdGhlIFdHIHRoYXQgaGF2ZSB0aGUgbmVjZXNzYXJ5IGV4cGVydGlzZSBmb3Ig dGhhdCBlbnZpcm9ubWVudCwgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJvdGggbW9iaWxlIGFuZCBmaXhlZCBuZXR3b3JrIG1heSBwdXQgdGhlaXIgU2Vydmlj ZSBGdW5jdGlvbnMgaW4gYSB2aXJ0dWFsIGVudmlyb25tZW50LCB3aGljaCBpcyB2ZXJ5IHBvc3Np Ymx5ICZuYnNwO2EgZGF0YWNlbnRlci4gU28sIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZQ0K IGhhcyBhIGdyZWF0IG92ZXJsYXAgd2l0aCBvdGhlciB1c2UgY2FzZSBkcmFmdHMgaW5jbHVkaW5n LCBldmVuIHRob3VnaCB5b3Ugd2FudCB0byBoYXZlIOKAnHNwZWNpZmljIGVudmlyb25tZW50c+KA nSBhbmQgY2xlYW4gY3V0cyBiZXR3ZWVuIHRoZW0uDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE3Ljg1cHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmFuZCB0aGF0 IGNhbiB3b3JrIGRpcmVjdGx5IHdpdGggdGhlIGFwcGxpY2FibGUgU0RPcyBvbiBpbmNvcnBvcmF0 aW5nIHJlbGV2YW50IGNvbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGVyZSB3YXMgYSBxdWVzdGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGFza2luZyB3 aGF0IGFyZSB0aGUgU0RPcyBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2UgaXMgY29ycmVzcG9u ZGluZyB0bywgYnV0IG5vIGFuc3dlciB3YXMgcG9zdGVkIHNvDQogZmFyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgaXQgc2VlbXMgZHJhZnQta3VtYXItc2ZjLWRjLXVz ZS1jYXNlIGRvZXNu4oCZdCBzZXJ2ZSB5b3VyIHB1cnBvc2UgYXQgYWxsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhvbmd5dTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5MdWN5IHlvbmc8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXks IEFwcmlsIDE5LCAyMDE0IDc6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFByb2dy ZXNzaW9uIG9mIFNGQyB1c2UgY2FzZSBkb2N1bWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBDaGFp cnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBlb3BsZSBpbmNs dWRpbmcgbXlzZWxmIGRpZCBub3Qgdm9pY2UgYSBzaW5nbGUgZG9jdW1lbnQgdG8gY2FwdHVyZSBh bGwgcG9zc2libGUgdXNlIGNhc2VzIGJlY2F1c2UgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyB0aGF0 LiBXZSBzdWdnZXN0ZWQNCiBjYXB0dXJpbmcgYWxsIG5lY2Vzc2FyeSB1c2UgY2FzZXMgdGhhdCBo ZWxwIGRyaXZpbmcgdGhlIGFyY2hpdGVjdHVyZSBhbmQgcmVxdWlyZW1lbnQgZGV2ZWxvcG1lbnQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkdpdmluZyB0aGUgc2l0dWF0aW9uLCBJIHN1cHBvcnQgYWRvcHRpbmcgZHJhZnQt aGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmxpdHkgYXMgV0cgZHJhZnQuIFRoaXMgaXMgYmVjYXVz ZSBhIGxhcmdlIHBvcnRpb24gb2YgU0ZDIHVzZSBjYXNlcw0KIGFyZSBpbiBNb2JpbGUgYXBwbGlj YXRpb25zOyBhbmQgdGhlIGRyYWZ0IGRlc2NyaWJlcyBtYW55IHVuaXF1ZSB3YXlzIHRvIHVzZSBT RkMuIEl0IGlzIGdvb2QgdG8gaGF2ZSBvbmUgZHJhZnQgdG8gY292ZXIgTW9iaWxlIGFyZWEuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPklNTzogZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcyBkb2VzIG5vdCBkZXBpY3Qg dW5pcXVlIFNGQyBjYXNlcyBmcm9tIGEgZ2VuZXJhbCBTRkMgY2FzZSBleGNlcHQgdGhlIFNGQyBh cHBsaWNhdGlvbnMgbG9jYXRpb24gaXMgaW4gZGF0YQ0KIGNlbnRlcnMuIFRodXMgdGhlc2UgY2Fz ZXMgY2FuIGJlIGVhc2lseSBtZXJnZWQgaW50byB0aGUgZ2VuZXJhbCB1c2UgY2FzZSBkcmFmdC4g U28gd2UgaGF2ZSBhbm90aGVyIHVzZSBjYXNlIGRyYWZ0IGZvciB0aGUgcmVzdC48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkx1Y3k8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVyZSBoYXMgYmVl biBtdWNoIGRpc2N1c3Npb24gYm90aCBvbiB0aGUgbGlzdCBhbmQgZHVyaW5nIG91ciBmYWNlLXRv LWZhY2UgbWVldGluZ3MgYWJvdXQgaG93IGJlc3QgdG8gcHJvZ3Jlc3MgdXNlIGNhc2UgZG9jdW1l bnRzIHdpdGhpbiB0aGUgV0cuDQogVGhlcmUgYXJlIGNsZWFybHkgYXJndW1lbnRzIGZvciBib3Ro IG9mIHRoZSBmb2xsb3dpbmcgYXBwcm9hY2hlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkEgc2luZ2xlIGRvY3VtZW50IHRoYXQgY2FwdHVyZXMgYWxsIG9m IHRoZSBwb3NzaWJsZSB1c2UgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkEgc21hbGwgbnVtYmVyIG9mIHRh cmdldGVkIGRvY3VtZW50cyB0aGF0IGFyZSBmb2N1c2VkIG9uIGEgcGFydGljdWxhciBzdWJzZXQg b2YgdGhlIG92ZXJhbGwgcHJvYmxlbSBzcGFjZSAoc3VjaCBhcyBicm9hZGJhbmQsIG1vYmlsaXR5 LCBhbmQgZGF0YSBjZW50ZXIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5CdXQsIHdlIGNhbuKAmXQgY2hvb3NlIGJvdGguIEluIGNvbnNpZGVy aW5nIHRoZXNlIGFwcHJvYWNoZXMsIHRoZSBjaGFpcnMgcmVjb2duaXplIHRoYXQgdGhlcmUgYXJl IGJlbmVmaXRzIHRvIGhhdmluZyBhIHNpbmdsZSBkb2N1bWVudCwgYnV0IGRvIG5vdA0KIGJlbGll dmUgaGF2aW5nIGp1c3Qgb25lIGRvY3VtZW50IGlzIHdvcmthYmxlIGluIHRoaXMgY2FzZS4gTm9y IGlzIHRoZXJlIGNvbnNlbnN1cyBmb3IgaGF2aW5nIGEgc2luZ2xlIGRvY3VtZW50LiAmbmJzcDtU aGVyZWZvcmUsIHdlIHdpbGwgcHVyc3VlIHRoZSBmb2xsb3dpbmcgYXBwcm9hY2ggZ29pbmcgZm9y d2FyZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxvbCBzdGFydD0iMiIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVs MSBsZm82Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFkb3B0 IGEgc21hbGwgbnVtYmVyIG9mIFdHIGRvY3VtZW50cyAoaW5pdGlhbGx5IDIpIHRoYXQgYXJlIGFw cGxpY2FibGUgdG8gc3BlY2lmaWMgZW52aXJvbm1lbnRzIGFuZCB0aGF0IGNhbiBiZSB3b3JrZWQg b24gaW5kZXBlbmRlbnRseSBieSBtZW1iZXJzIG9mIHRoZSBXRyB0aGF0IGhhdmUgdGhlIG5lY2Vz c2FyeQ0KIGV4cGVydGlzZSBmb3IgdGhhdCBlbnZpcm9ubWVudCwgYW5kIHRoYXQgY2FuIHdvcmsg ZGlyZWN0bHkgd2l0aCB0aGUgYXBwbGljYWJsZSBTRE9zIG9uIGluY29ycG9yYXRpbmcgcmVsZXZh bnQgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzYiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29udGludWUgdG8gbGVhdmUgb3BlbiB0aGUgcG9zc2li aWxpdHkgb2YgYWRvcHRpbmcgYSBoaWdoLWxldmVsIHVzZSBjYXNlIGRvY3VtZW50IHRoYXQgc2Vy dmVzIGFzIGEg4oCcY2F0Y2ggYWxs4oCdIGZvciB1c2UgY2FzZXMgdGhhdCBkbyBub3QgbWVyaXQg dGhlaXIgb3duIGRvY3VtZW50IG9yIGFyZSBub3QgY2FwdHVyZWQNCiBpbiB0aGUgY29udGVudCBv ZiBtb3JlIGZvY3VzZWQgdXNlIGNhc2UgZG9jdW1lbnRzLiBIb3dldmVyLCBiZWZvcmUgdGFraW5n IG9uIHN1Y2ggYSBkb2N1bWVudCwgdGhlIFdHIHdpbGwgbmVlZCB0byB1bmRlcnN0YW5kIGluIG1v cmUgZGV0YWlsIHdoYXQgdGhlIGNvbnRlbnQgd291bGQgYmUgYW5kIHRoYXQgdGhlIGNvbnRlbnQg anVzdGlmaWVzIGhhdmluZyBzdWNoIGEgZG9jdW1lbnQuIFN1Y2ggYSBkb2N1bWVudCBzaG91bGQg bm90IGR1cGxpY2F0ZQ0KIG1hdGVyaWFsIHRoYXQgaXMgY292ZXJlZCBpbiBvdGhlciBkb2N1bWVu dHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPlRvIGZhY2lsaXRhdGUgdGhlIGFib3ZlIGRpcmVjdGlvbiB0aGUgY2hhaXJzIHdpbGwg dGFrZSB0aGUgZm9sbG93aW5nIHN0ZXBzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzkiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Q2FsbCBmb3IgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LWhhZWZmbmVyLXNm Yy11c2UtY2FzZS1tb2JsaXR5IGFuZCBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzIGFzIFdH IGRvY3VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzkiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RW5jb3VyYWdlIHRoZSBhdXRob3JzIHRvIGNvbnRpbnVl IHRvIHdvcmsgb24gcmVmaW5lbWVudCBvZiBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy4gVGhlIGF1 dGhvcnMgb2YgdGhhdCBkb2N1bWVudCBzaG91bGQgdXBkYXRlIHRoZWlyIGRyYWZ0IHRvIHJlbW92 ZSBhbnkgZHVwbGljYXRpb24gb2YgbWF0ZXJpYWwgY292ZXJlZA0KIGluIG90aGVyIGRvY3VtZW50 cyBhcyB3ZWxsIGFzIGlkZW50aWZ5IGNvbnRlbnQgdGhhdCBpcyBub3QgY292ZXJlZCBlbHNld2hl cmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPldlIGhvcGUgdGhhdCB0aGlzIGFwcHJvYWNoIHdpbGwgYWxsb3cgdGhlIFdHIHRvIG1v dmUgZm9yd2FyZCBhbmQgYWxzbyBwcm92aWRlIGVub3VnaCBmbGV4aWJpbGl0eSB0byBhbGxvdyB1 c2UgY2FzZXMgdG8gZXZvbHZlIGluZGVwZW5kZW50bHksIHdpdGgNCiBkaXJlY3QgaW50ZXJhY3Rp b24gd2l0aCB0aGUgYXBwcm9wcmlhdGUgU0RPcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmltICZhbXA7 IFRob21hczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6EB34CB5D82C4645B826C56144826EA97E9F312ASZXEMA509MBXchi_-- From nobody Tue Apr 22 06:21: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 9D88A1A0476 for ; Tue, 22 Apr 2014 06:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.172 X-Spam-Level: X-Spam-Status: No, score=-7.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 RAhN9fddER7r for ; Tue, 22 Apr 2014 06:21:49 -0700 (PDT) Received: from mxebdp03ex-public.idz.gs.com (mxe6.gs.com [207.17.33.102]) by ietfa.amsl.com (Postfix) with ESMTP id C47441A046F for ; Tue, 22 Apr 2014 06:21:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,904,1389762000"; d="scan'208,217";a="120660854" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxebdp03ex.idz.gs.com with ESMTP; 22 Apr 2014 09:21:42 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp09ex.firmwide.corp.gs.com ([10.135.172.18]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 22 Apr 2014 09:21:42 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp09ex.firmwide.corp.gs.com ([10.135.172.18]) with mapi; Tue, 22 Apr 2014 09:21:42 -0400 To: "'Diego R. Lopez'" , 'Martin Stiemerling' Date: Tue, 22 Apr 2014 09:21:41 -0400 Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPXfX8AOPSq8hgAk+U/Es2OhguNpsdEFYAgACJ6/A= Message-ID: References: <581EAA0A-3BCB-494F-A624-F0C17B3DAA27@gmail.com> <17B07080-6CF0-49A2-9770-C8A8BB542791@tid.es> In-Reply-To: <17B07080-6CF0-49A2-9770-C8A8BB542791@tid.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23070409A96FGSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KXI2Yu3HgzafbTfS5hlJC13_30c Cc: "'Jim Guichard \(jguichar\)'" , "'sfc@ietf.org'" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 22 Apr 2014 13:21:55 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A96FGSCMAMP19EXfi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you, Diego. It's exactly what I meant. Martin, I'm coming from the user side. From an enterprise user perspective,= we'd like to see existing (non-SFC-understanding) equipment (FWs, LBs, etc= .) still be usable inside service chains. I think SFC solutions that can ac= commodate legacy equipment will find wider adoption. Also, I'm saying "SHOULD not require", not "MUST not require". I'm not an e= xpert on RFC-2119 terms, so I'll be fine with a more suitable wording to th= at effect. Regards, -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Diego R. Lopez Sent: 22 April 2014 2:49 AM To: Martin Stiemerling Cc: Jim Guichard (jguichar); Zarny, Myo [Tech]; sfc@ietf.org Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobilit= y-01 Hi, As far as I understand, it says that SFC implementations should be complete= ly oblivious to the processing performed by the service functions, and shou= ld not rely on them to actually implement chaining and paths. It simplifies= the way for legacy functions being integrated in a SFC framework, Be goode, On 22 Apr 2014, at 08:41 , Martin Stiemerling > wrote: > Hi, > Am 22.04.2014 um 00:03 schrieb Zarny, Myo >: > >> I like the requirements listed in 3.1.2. >> >> Shouldn't we also call this out? >> =B7 SFC solutions SHOULD not require any service functions to pa= rticipate in the implementation of SFCs. > > Isn't this a bit too strong? I assume you are coming from the legacy side= , i.e., existing functions should be able to include in SFCs. However, this= statement says that no function should be required to changed in order to = participate in SFCs. > > Or what does it mean? > > Martin > >> >> That is, service function nodes (LBs, proxys, FWs, etc.) need not unders= tand anything about SFCs; they could just be performing as they are today. = We could have service functions that partake in SFC implementations but the= y don't need to be required to. >> >> Regards, >> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguic= har) >> Sent: 18 April 2014 6:30 PM >> To: sfc@ietf.org >> Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility= -01 >> >> Dear WG: >> >> This message begins a two week call for WG adoption of the document http= ://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd M= ay 2014. >> >> Please respond to the SFC mailing list with any statements of approval o= r disapproval. >> >> 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 t= hat the content is solid. Therefore, please don't oppose adoption just beca= use you want to see changes to its content. >> 2. If you have objections to adoption of the document, please stat= e 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 i= ssues and we can begin a dialog about how best to address them. >> _______________________________________________ >> 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A96FGSCMAMP19EXfi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you, Diego. It's exactly what I meant.
 
Martin, I'm coming from the user side. From an= enterprise user perspective, we'd like to see existing (non-SFC-understand= ing) equipment (FWs, LBs, etc.) still be usable inside service chains. I th= ink SFC solutions that can accommodate legacy equipment will find wider adoption.
 
Also, I'm saying "SHOULD not require"= ;, not "MUST not require". I’m not an expert on RFC-2119 te= rms, so I’ll be fine with a more suitable wording to that effect.
 
Regards,
 
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Diego R. Lopez
Sent: 22 April 2014 2:49 AM
To: Martin Stiemerling
Cc: Jim Guichard (jguichar); Zarny, Myo [Tech]; sfc@ietf.org
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobilit= y-01
 
Hi,
 
As far as I understand, it says that SFC implementations should be com= pletely oblivious to the processing performed by the service functions, and= should not rely on them to actually implement chaining and paths. It simpl= ifies the way for legacy functions being integrated in a SFC framework,
 
Be goode,
 
On 22 Apr 2014, at 08:41 , Martin Stiemerling <mls.ietf@gmail.com> wrote:
 
> Hi,
> Am 22.04.2014 um 00:03 schrieb Zarny, Myo <Myo.Zarny@gs.com>:
>
>> I like the requirements listed in 3.1.2.
>>
>> Shouldn’t we also call this out?
>> =B7         SFC solut= ions SHOULD not require any service functions to participate in the impleme= ntation of SFCs.
>
> Isn’t this a bit too strong? I assume you are coming from t= he legacy side, i.e., existing functions should be able to include in SFCs.= However, this statement says that no function should be required to change= d in order to participate in SFCs.
>
> Or what does it mean?
>
>  Martin
>
>>
>> That is, service function nodes (LBs, proxys, FWs, etc.) need= not understand anything about SFCs; they could just be performing as they = are today. We could have service functions that partake in SFC implementati= ons but they don’t need to be required to.
>>
>> Regards,
>>
>> From: sfc [mailto:sfc= -bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
>> Sent: 18 April 2014 6:30 PM
>> Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-ca= se-mobility-01
>>
>> Dear WG:
>>
>> This message begins a two week call for WG adoption of the do= cument http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.t= xt ending 2nd May 2014.
>>
>> Please respond to the SFC mailing list with any statements of= approval or disapproval.
>>
>> Please note:
>> 1.       This is not WG Last Ca= ll. The document is not final, and the WG is expected to modify the documen= t’s content until there is WG consensus that the content is solid. Th= erefore, please don’t oppose adoption just because you want to see ch= anges to its content.
>> 2.       If you have objections= to adoption of the document, please state your reasons why, and explain wh= at it would take to address your concerns.
>> 3.       If you have issues wit= h the content, by all means raise those issues and we can begin a dialog ab= out how best to address them.
>> _______________________________________________
>> sfc mailing list
>
> _______________________________________________
> sfc mailing list
 
 
--
"Esta vez no fallaremos, Doctor Infierno"
 
Dr Diego R. Lopez
Telefonica I+D
 
e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------
 
 
________________________________
 
Este mensaje se dirige exclusivamente a su destinatario. Puede consult= ar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l enlace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send a= nd receive email on the basis of the terms set out at:
 
_______________________________________________
sfc mailing list
 
 --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A96FGSCMAMP19EXfi_-- From nobody Tue Apr 22 06:52: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 422B81A047D for ; Tue, 22 Apr 2014 06:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 fkzUUCM1LS5m for ; Tue, 22 Apr 2014 06:52:42 -0700 (PDT) Received: from mxecd08.gs.com (mxe7.gs.com [204.4.178.100]) by ietfa.amsl.com (Postfix) with ESMTP id 715821A0495 for ; Tue, 22 Apr 2014 06:52:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,904,1389762000"; d="scan'208,217";a="2182612" Received: from unknown (HELO mxpcd02-public.ny.fw.gs.com) ([148.86.97.79]) by mxecd08.idz.gs.com with ESMTP; 22 Apr 2014 09:52:20 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp03ex.firmwide.corp.gs.com ([10.135.172.73]) by cd02-mxp-vip-prod.ny.fw.gs.com with ESMTP; 22 Apr 2014 09:52:20 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp03ex.firmwide.corp.gs.com ([10.135.172.73]) with mapi; Tue, 22 Apr 2014 09:52:20 -0400 To: 'Jmh.direct' , "'jmh@joelhalpern.com'" , "'sfc@ietf.org'" Date: Tue, 22 Apr 2014 09:52:18 -0400 Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: Ac9duo0IsMqptwnaTzaG+1YYWNN4OwAc4wWQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23070409A981GSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4Fjt8IgUWNKqJy8bLY7FBIlqXk4 Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 22 Apr 2014 13:52:48 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A981GSCMAMP19EXfi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmZWVsIGxpa2UgdGhlIHByb3h5aW5nIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQgaXMgZm9yIHNv bWUgb3RoZXIgU0ZDIHBhcnRpY2lwYXRpbmcvZW5hYmxpbmcgbm9kZXMuDQoNCk15IG9yaWdpbmFs IGNvbW1lbnQgd2FzIG9uIHNlcnZpY2UgZnVuY3Rpb24gbm9kZXMgKGxpa2UgRldzLCBMQnMpLCBu b3QgU0ZDIGVuYWJsaW5nIG5vZGVzIGxpa2UgZm9yd2FyZGluZyBvciBjbGFzc2lmaWNhdGlvbiBu b2Rlcy4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhlIGRyYWZ0IGRvZXNu4oCZdOKAlGNvcnJlY3Rs eSBJTU/igJRyZXF1aXJlIOKAnHByb3h5aW5n4oCdIHNlcnZpY2UgZnVuY3Rpb25zIG9ubHkgKHNp bmNlIGl0IGluY2x1ZGVzIGZpcmV3YWxscyBhcyBvbmUgb2YgdGhlIHBvc3NpYmxlIHNlcnZpY2Ug ZnVuY3Rpb25zKS4NCg0KUmVnYXJkcywNCg0KRnJvbTogSm1oLmRpcmVjdCBbbWFpbHRvOmptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KU2VudDogMjEgQXByaWwgMjAxNCA3OjM2IFBNDQpUbzog WmFybnksIE15byBbVGVjaF07IGptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWhhZWZmbmVyLXNmYy11 c2UtY2FzZS1tb2JpbGl0eS0wMQ0KSW1wb3J0YW5jZTogTG93DQoNCldpdGhvdXQgc29tZSBmaXJt IG9mIHByb3h5IGFueSBleGlzdGluZyBmdW5jdGlvbiB3aWxsLCBpZiB1c2VkIGluIHNmYywgbG9z ZSB0Z2UgdHJhbnNwb3J0IGhlYWRlciBhbmQgdGhlIHNmYyBzcGVjaWZpYyBoZWFkZXIuDQoNCllv dXJzLA0KSm9lbA0KDQoNClNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmVA0K DQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogUkU6IFtz ZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWhhZWZmbmVyLXNmYy11c2UtY2FzZS1tb2Jp bGl0eS0wMQ0KRnJvbTogIlphcm55LCBNeW8iIDxNeW8uWmFybnlAZ3MuY29tPG1haWx0bzpNeW8u WmFybnlAZ3MuY29tPj4NClRvOiAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sIidzZmNAaWV0Zi5vcmcnIiA8c2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KQ0M6DQoNCkhpIEpvZWwsDQoNCk5vdCBzdXJl IGFib3V0IHRoZSBjb21tZW50IGFib3V0IHRoZSBuZWVkIGZvciBwcm94eWluZyBhcyBhIHJlcXVp cmVtZW50IGZvciBTRkMuIE5vdCBhbGwgc2VydmljZSBmdW5jdGlvbnMgYXJlIG9mIHByb3h5aW5n IGtpbmQuIEV2ZW4gbG9hZCBiYWxhbmNlcnMgZG9uJ3QgaGF2ZSB0byBwcm94eS0tRFNSIGZvciBl eGFtcGxlLiBGaXJld2FsbHMgcGVyZm9ybSBwZXJtaXQvZGVueTsgdGhleSBkb27igJl0IHByb3h5 LiBMaWtld2lzZSB3aXRoIElEUy9JUFMuIEV0Yy4gRXRjLiBTaG91bGRu4oCZdCB3ZSBhc3N1bWUg dGhhdCBzZXJ2aWNlIGNoYWlucyB3aWxsIGNvbnNpc3Qgb2YgcHJveHlpbmcgYW5kIG5vbi1wcm94 eWluZyBraW5kcz8gQmVzaWRlcywgSSBkb27igJl0IHJlYWQgdGhhdCB0aGUgZHJhZnQgcmVxdWly ZXMgcHJveHlpbmcsIGRvIHlvdT8NCg0KSeKAmW0gbm90IHNheWluZyBzZXJ2aWNlIGZ1bmN0aW9u IG5vZGVzIGNhbuKAmXQgcGFydGFrZSBpbiBTRkMgaW1wbGVtZW50YXRpb25z4oCUbm8gbmVlZCB0 byBzdGlmbGUgaW5ub3ZhdGlvbi4gQnV0IGRvIHdlIG5lZWQgdG8gcmVxdWlyZSB0aGF0IHNlcnZp Y2UgZnVuY3Rpb24gbm9kZXMgTVVTVCB1bmRlcnN0YW5kIFNGQyBoZWFkZXJzLCBmb3IgZXhhbXBs ZT8gV2hhdCBoYXBwZW5zIHRvIHRob3NlIHRoYXQgZG9u4oCZdD8gQXJlIHRoZXkgYWxsIGxlZ2Fj eT8gRm9yIG1hbnkgdXNlcnMgd2hvIGhhdmUgaW52ZXN0ZWQgaW4gbm9uLVNGQy11bmRlcnN0YW5k aW5nIGVxdWlwbWVudCwgdGhhdOKAmXMgcHJhY3RpY2FsbHkgYSBub24tc3RhcnRlci4gQW5kIGl0 IHdpbGwgbGlrZWx5IHNsb3cgYWRvcHRpb24sIElNTy4NCg0KUmVnYXJkcywNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb21dDQpTZW50OiAyMSBBcHJpbCAyMDE0IDY6MjIgUE0NClRvOiBaYXJueSwgTXlv IFtUZWNoXTsgJ3NmY0BpZXRmLm9yZycNClN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBhZG9w dGlvbiBvZiBkcmFmdC1oYWVmZm5lci1zZmMtdXNlLWNhc2UtbW9iaWxpdHktMDENCg0KSSB3b3Vs ZCBwcmVmZXIgbm90IHRvIHN0YXRlIHRoYXQgYXMgYSByZXF1aXJlbWVudC4NCldoZXJlIHByYWN0 aWNhbCwgd2UgZG8gaW5kZWVkIHdhbnQgKGV2ZW4gbmVlZCkgdG8gc3VwcG9ydCBleGlzdGluZyBz ZXJ2aWNlIGZ1bmNpdG9uIGltcGxlbWVudGF0aW9ucy4NCkJ1dCB0aGVyZSB3aWxsIGJlIHNvbWUg c2VydmljZSBmdW5jdGlvbnMgd2hpY2ggY2FuIG5vdCBiZSBwcm94aWVkIGFuZCB3aGljaCBjYW4g bm90IGJlIHBsYWNlZCBpbnRvIHRoZSBtaWRkbGUgb2Ygc2VydmljZSBjaGFpbnMuICBUcnlpbmcg dG8gc29sdmUgMTAwJSBvZiB0aGUgY2FzZXMsIGlmIHBvc3NpYmxlIGF0IGFsbCwgd2lsbCBsaWtl bHkgZHJhbWF0aWNhbGx5IHNsb3cgdGhlIHdvcmsgZG93bi4NCg0KWW91cnMsDQpKb2VsIE0uIEhh bHBlcm4NCg0KT24gNC8yMS8xNCwgNjowMyBQTSwgWmFybnksIE15byB3cm90ZToNCj4gSSBsaWtl IHRoZSByZXF1aXJlbWVudHMgbGlzdGVkIGluIDMuMS4yLg0KPg0KPiBTaG91bGRu4oCZdCB3ZSBh bHNvIGNhbGwgdGhpcyBvdXQ/DQo+DQo+IMK3U0ZDIHNvbHV0aW9ucyBTSE9VTEQgbm90IHJlcXVp cmUgYW55IHNlcnZpY2UgZnVuY3Rpb25zIHRvIHBhcnRpY2lwYXRlDQo+IGluIHRoZSBpbXBsZW1l bnRhdGlvbiBvZiBTRkNzLg0KPg0KPiBUaGF0IGlzLCBzZXJ2aWNlIGZ1bmN0aW9uIG5vZGVzIChM QnMsIHByb3h5cywgRldzLCBldGMuKSBuZWVkIG5vdA0KPiB1bmRlcnN0YW5kIGFueXRoaW5nIGFi b3V0IFNGQ3M7IHRoZXkgY291bGQganVzdCBiZSBwZXJmb3JtaW5nIGFzIHRoZXkNCj4gYXJlIHRv ZGF5LiBXZSBjb3VsZCBoYXZlIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgcGFydGFrZSBpbiBTRkMN Cj4gaW1wbGVtZW50YXRpb25zIGJ1dCB0aGV5IGRvbuKAmXQgbmVlZCB0byBiZSByZXF1aXJlZCB0 by4NCj4NCj4gUmVnYXJkcywNCj4NCj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSAqT24gQmVoYWxmIE9mICpKaW0gR3VpY2hhcmQNCj4gKGpndWljaGFyKQ0KPiAqU2Vu dDoqIDE4IEFwcmlsIDIwMTQgNjozMCBQTQ0KPiAqVG86KiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4gKlN1YmplY3Q6KiBbc2ZjXSBDYWxsIGZvciBhZG9wdGlvbiBvZg0KPiBk cmFmdC1oYWVmZm5lci1zZmMtdXNlLWNhc2UtbW9iaWxpdHktMDENCj4NCj4gRGVhciBXRzoNCj4N Cj4gVGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9m IHRoZSBkb2N1bWVudA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWhhZWZmbmVyLXNm Yy11c2UtY2FzZS1tb2JpbGl0eS0wMS50eHQNCj4gZW5kaW5nIDJuZCBNYXkgMjAxNC4NCj4NCj4g UGxlYXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5nIGxpc3Qgd2l0aCBhbnkgc3RhdGVtZW50 cyBvZiBhcHByb3ZhbA0KPiBvciBkaXNhcHByb3ZhbC4NCj4NCj4gUGxlYXNlIG5vdGU6DQo+DQo+ IDEuVGhpcyBpcyBub3QgV0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMgbm90IGZpbmFsLCBh bmQgdGhlIFdHIGlzDQo+IGV4cGVjdGVkIHRvIG1vZGlmeSB0aGUgZG9jdW1lbnTigJlzIGNvbnRl bnQgdW50aWwgdGhlcmUgaXMgV0cgY29uc2Vuc3VzDQo+IHRoYXQgdGhlIGNvbnRlbnQgaXMgc29s aWQuIFRoZXJlZm9yZSwgcGxlYXNlIGRvbuKAmXQgb3Bwb3NlIGFkb3B0aW9uDQo+IGp1c3QgYmVj YXVzZSB5b3Ugd2FudCB0byBzZWUgY2hhbmdlcyB0byBpdHMgY29udGVudC4NCj4NCj4gMi5JZiB5 b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNlIHN0 YXRlDQo+IHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0 byBhZGRyZXNzIHlvdXIgY29uY2VybnMuDQo+DQo+IDMuSWYgeW91IGhhdmUgaXNzdWVzIHdpdGgg dGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSBpc3N1ZXMNCj4gYW5kIHdlIGNh biBiZWdpbiBhIGRpYWxvZyBhYm91dCBob3cgYmVzdCB0byBhZGRyZXNzIHRoZW0uDQo+DQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNm YyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCg== --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A981GSCMAMP19EXfi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBmZWVs IGxpa2UgdGhlIHByb3h5aW5nIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQgaXMgZm9yIHNvbWUgb3Ro ZXIgU0ZDIHBhcnRpY2lwYXRpbmcvZW5hYmxpbmcgbm9kZXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ TXkgb3JpZ2luYWwgY29tbWVudCB3YXMgb24gPGk+c2VydmljZSBmdW5jdGlvbiBub2RlczwvaT4g KGxpa2UgRldzLCBMQnMpLCBub3QgU0ZDIGVuYWJsaW5nIG5vZGVzIGxpa2UgZm9yd2FyZGluZyBv ciBjbGFzc2lmaWNhdGlvbiBub2Rlcy4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhlIGRyYWZ0IGRv ZXNu4oCZdOKAlGNvcnJlY3RseSBJTU/igJRyZXF1aXJlIOKAnHByb3h5aW5n4oCdIHNlcnZpY2Ug ZnVuY3Rpb25zIG9ubHkgKHNpbmNlIGl0IGluY2x1ZGVzIGZpcmV3YWxscyBhcyBvbmUgb2YgdGhl IHBvc3NpYmxlIHNlcnZpY2UgZnVuY3Rpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEptaC5kaXJlY3QgW21haWx0bzpqbWguZGly ZWN0QGpvZWxoYWxwZXJuLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiAyMSBBcHJpbCAyMDE0IDc6MzYg UE08YnI+PGI+VG86PC9iPiBaYXJueSwgTXlvIFtUZWNoXTsgam1oQGpvZWxoYWxwZXJuLmNvbTsg c2ZjQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW3NmY10gQ2FsbCBmb3IgYWRvcHRp b24gb2YgZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmlsaXR5LTAxPGJyPjxiPkltcG9y dGFuY2U6PC9iPiBMb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPldpdGhvdXQgc29tZSBm aXJtIG9mIHByb3h5IGFueSBleGlzdGluZyBmdW5jdGlvbiB3aWxsLCBpZiB1c2VkIGluIHNmYywg bG9zZSB0Z2UgdHJhbnNwb3J0IGhlYWRlciBhbmQgdGhlIHNmYyBzcGVjaWZpYyBoZWFkZXIuPG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz5Zb3Vycyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Sm9lbDxicj48YnI+PGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0Jz5TZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFy dHBob25lIG9uIEFUJmFtcDtUPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluJz48YnI+PGJyPjxicj4tLS0tLS0t LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPlN1YmplY3Q6IFJFOiBbc2ZjXSBDYWxsIGZv ciBhZG9wdGlvbiBvZiBkcmFmdC1oYWVmZm5lci1zZmMtdXNlLWNhc2UtbW9iaWxpdHktMDEgPGJy PkZyb206ICZxdW90O1phcm55LCBNeW8mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpNeW8uWmFy bnlAZ3MuY29tIj5NeW8uWmFybnlAZ3MuY29tPC9hPiZndDsgPGJyPlRvOiAmcXVvdDsnSm9lbCBN LiBIYWxwZXJuJyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i PmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywmcXVvdDsnc2ZjQGlldGYub3JnJyZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDsgPGJy PkNDOiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5IaSBKb2VsLDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5Ob3Qgc3VyZSBhYm91dCB0aGUgY29tbWVudCBhYm91dCB0aGUg bmVlZCBmb3IgcHJveHlpbmcgYXMgYSByZXF1aXJlbWVudCBmb3IgU0ZDLiBOb3QgYWxsIHNlcnZp Y2UgZnVuY3Rpb25zIGFyZSBvZiBwcm94eWluZyBraW5kLiBFdmVuIGxvYWQgYmFsYW5jZXJzIGRv bid0IGhhdmUgdG8gcHJveHktLURTUiBmb3IgZXhhbXBsZS4gRmlyZXdhbGxzIHBlcmZvcm0gcGVy bWl0L2Rlbnk7IHRoZXkgZG9u4oCZdCBwcm94eS4gTGlrZXdpc2Ugd2l0aCBJRFMvSVBTLiBFdGMu IEV0Yy4gU2hvdWxkbuKAmXQgd2UgYXNzdW1lIHRoYXQgc2VydmljZSBjaGFpbnMgd2lsbCBjb25z aXN0IG9mIHByb3h5aW5nIGFuZCBub24tcHJveHlpbmcga2luZHM/IEJlc2lkZXMsIEkgZG9u4oCZ dCByZWFkIHRoYXQgdGhlIGRyYWZ0IHJlcXVpcmVzIHByb3h5aW5nLCBkbyB5b3U/PC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PknigJltIG5vdCBzYXlpbmcgc2VydmljZSBmdW5jdGlvbiBub2RlcyBjYW7igJl0IHBhcnRha2Ug aW4gU0ZDIGltcGxlbWVudGF0aW9uc+KAlG5vIG5lZWQgdG8gc3RpZmxlIGlubm92YXRpb24uIEJ1 dCBkbyB3ZSBuZWVkIHRvIHJlcXVpcmUgdGhhdCBzZXJ2aWNlIGZ1bmN0aW9uIG5vZGVzIE1VU1Qg dW5kZXJzdGFuZCBTRkMgaGVhZGVycywgZm9yIGV4YW1wbGU/IFdoYXQgaGFwcGVucyB0byB0aG9z ZSB0aGF0IGRvbuKAmXQ/IEFyZSB0aGV5IGFsbCBsZWdhY3k/IEZvciBtYW55IHVzZXJzIHdobyBo YXZlIGludmVzdGVkIGluIG5vbi1TRkMtdW5kZXJzdGFuZGluZyBlcXVpcG1lbnQsIHRoYXTigJlz IHByYWN0aWNhbGx5IGEgbm9uLXN0YXJ0ZXIuIEFuZCBpdCB3aWxsIGxpa2VseSBzbG93IGFkb3B0 aW9uLCBJTU8uPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT5d IDxicj5TZW50OiAyMSBBcHJpbCAyMDE0IDY6MjIgUE08YnI+VG86IFphcm55LCBNeW8gW1RlY2hd OyAnc2ZjQGlldGYub3JnJzxicj5TdWJqZWN0OiBSZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24g b2YgZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmlsaXR5LTAxPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkkgd291bGQg cHJlZmVyIG5vdCB0byBzdGF0ZSB0aGF0IGFzIGEgcmVxdWlyZW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz5XaGVyZSBwcmFjdGljYWwsIHdlIGRvIGluZGVlZCB3YW50IChldmVuIG5l ZWQpIHRvIHN1cHBvcnQgZXhpc3Rpbmcgc2VydmljZSBmdW5jaXRvbiBpbXBsZW1lbnRhdGlvbnMu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5CdXQgdGhlcmUgd2lsbCBiZSBzb21lIHNlcnZp Y2UgZnVuY3Rpb25zIHdoaWNoIGNhbiBub3QgYmUgcHJveGllZCBhbmQgd2hpY2ggY2FuIG5vdCBi ZSBwbGFjZWQgaW50byB0aGUgbWlkZGxlIG9mIHNlcnZpY2UgY2hhaW5zLiZuYnNwOyBUcnlpbmcg dG8gc29sdmUgMTAwJSBvZiB0aGUgY2FzZXMsIGlmIHBvc3NpYmxlIGF0IGFsbCwgd2lsbCBsaWtl bHkgZHJhbWF0aWNhbGx5IHNsb3cgdGhlIHdvcmsgZG93bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+WW91cnMsPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiJz5Kb2VsIE0uIEhhbHBlcm48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+T24gNC8yMS8xNCwgNjow MyBQTSwgWmFybnksIE15byB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsg SSBsaWtlIHRoZSByZXF1aXJlbWVudHMgbGlzdGVkIGluIDMuMS4yLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIic+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OyBT aG91bGRu4oCZdCB3ZSBhbHNvIGNhbGwgdGhpcyBvdXQ/PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IMK3U0ZDIHNv bHV0aW9ucyBTSE9VTEQgbm90IHJlcXVpcmUgYW55IHNlcnZpY2UgZnVuY3Rpb25zIHRvIHBhcnRp Y2lwYXRlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OyBpbiB0aGUgaW1wbGVtZW50 YXRpb24gb2YgU0ZDcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsgVGhhdCBpcywgc2VydmljZSBmdW5jdGlvbiBu b2RlcyAoTEJzLCBwcm94eXMsIEZXcywgZXRjLikgbmVlZCBub3QgPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mZ3Q7IHVuZGVyc3RhbmQgYW55dGhpbmcgYWJvdXQgU0ZDczsgdGhleSBjb3Vs ZCBqdXN0IGJlIHBlcmZvcm1pbmcgYXMgdGhleSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PiZndDsgYXJlIHRvZGF5LiBXZSBjb3VsZCBoYXZlIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgcGFy dGFrZSBpbiBTRkMgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IGltcGxlbWVudGF0 aW9ucyBidXQgdGhleSBkb27igJl0IG5lZWQgdG8gYmUgcmVxdWlyZWQgdG8uPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4m Z3Q7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gKk9u IEJlaGFsZiBPZiAqSmltIEd1aWNoYXJkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7 IChqZ3VpY2hhcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsgKlNlbnQ6KiAxOCBB cHJpbCAyMDE0IDY6MzAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsgKlRvOiog PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+Jmd0OyAqU3ViamVjdDoqIFtzZmNdIENhbGwgZm9yIGFkb3B0aW9u IG9mPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IGRyYWZ0LWhhZWZmbmVyLXNmYy11 c2UtY2FzZS1tb2JpbGl0eS0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OyBEZWFyIFdHOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0 OyBUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgdHdvIHdlZWsgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2Yg dGhlIGRvY3VtZW50IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OyA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWhhZWZmbmVyLXNmYy11c2UtY2FzZS1tb2JpbGl0 eS0wMS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1j YXNlLW1vYmlsaXR5LTAxLnR4dDwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7 IGVuZGluZyAybmQgTWF5IDIwMTQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IFBsZWFzZSByZXNwb25kIHRvIHRo ZSBTRkMgbWFpbGluZyBsaXN0IHdpdGggYW55IHN0YXRlbWVudHMgb2YgYXBwcm92YWwgPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IG9yIGRpc2FwcHJvdmFsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0 OyBQbGVhc2Ugbm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsgMS5UaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwu IFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWwsIGFuZCB0aGUgV0cgaXMgPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz4mZ3Q7IGV4cGVjdGVkIHRvIG1vZGlmeSB0aGUgZG9jdW1lbnTigJlzIGNv bnRlbnQgdW50aWwgdGhlcmUgaXMgV0cgY29uc2Vuc3VzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+Jmd0OyB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBk b27igJl0IG9wcG9zZSBhZG9wdGlvbiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsg anVzdCBiZWNhdXNlIHlvdSB3YW50IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+Jmd0OyAyLklmIHlvdSBoYXZlIG9iamVjdGlvbnMgdG8gYWRvcHRpb24gb2YgdGhlIGRv Y3VtZW50LCBwbGVhc2Ugc3RhdGUgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IHlv dXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNz IHlvdXIgY29uY2VybnMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7IDMuSWYgeW91IGhhdmUgaXNzdWVzIHdpdGgg dGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSBpc3N1ZXMgPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4mZ3Q7IGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93 IGJlc3QgdG8gYWRkcmVzcyB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OyBzZmMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_A3233753A4B65F43BCA1B64DA99A9C23070409A981GSCMAMP19EXfi_-- From nobody Tue Apr 22 07:24: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 B01A31A049C for ; Tue, 22 Apr 2014 07:24:38 -0700 (PDT) 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 FjshVI6L5XTj for ; Tue, 22 Apr 2014 07:24:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DD6551A047E for ; Tue, 22 Apr 2014 07:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D50DC1C04AE; Tue, 22 Apr 2014 07:24:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2D2061C0499; Tue, 22 Apr 2014 07:24:28 -0700 (PDT) Message-ID: <53567B97.6020205@joelhalpern.com> Date: Tue, 22 Apr 2014 10:24:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Zarny, Myo" , "'sfc@ietf.org'" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oYLUyOOKWfNrKo9k8FaQI7RQxV4 Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 22 Apr 2014 14:24:38 -0000 You asked for an added requirement that SFC SHOULD not require any changes to an SF for it to be used in SFC service chaining. While a desirable goal, I expressed concern about it as a requirement. My point is that structuring SFC so that all existing applications will work with it adds significant complexity to SFC. Settling for 80% (or 90% if we can) coverage, and recognizing that some applications will need to be change to be used as service functions in SFC, will make our job achievable. We can use chain proxies in SFC to enable many existing applications to be used in SFC without modification. This was an example of a tool we are likely to need to use to get even 80% coverage. So I mentioned it to be clear that I was not trying to exclude that from our work. I did not try to itemize what applications would not be supported. I hope that the number of those is small. But we will find out down the road. Yours, Joel PS: It is always difficult for readers to be sure what we intend when we put a "should" in a requirements document. On 4/22/14, 9:52 AM, Zarny, Myo wrote: > I feel like the proxying you’re talking about is for some other SFC > participating/enabling nodes. > > My original comment was on /service function nodes/ (like FWs, LBs), not > SFC enabling nodes like forwarding or classification nodes. As far as I > can see, the draft doesn’t—correctly IMO—require “proxying†service > functions only (since it includes firewalls as one of the possible > service functions). > > Regards, > > *From:*Jmh.direct [mailto:jmh.direct@joelhalpern.com] > *Sent:* 21 April 2014 7:36 PM > *To:* Zarny, Myo [Tech]; jmh@joelhalpern.com; sfc@ietf.org > *Subject:* RE: [sfc] Call for adoption of > draft-haeffner-sfc-use-case-mobility-01 > *Importance:* Low > > Without some firm of proxy any existing function will, if used in sfc, > lose tge transport header and the sfc specific header. > > Yours, > > Joel > > > Sent from my Samsung smartphone on AT&T > > > > > -------- Original message -------- > Subject: RE: [sfc] Call for adoption of > draft-haeffner-sfc-use-case-mobility-01 > From: "Zarny, Myo" > > To: "'Joel M. Halpern'" >,"'sfc@ietf.org'" > > CC: > > Hi Joel, > > Not sure about the comment about the need for proxying as a requirement > for SFC. Not all service functions are of proxying kind. Even load > balancers don't have to proxy--DSR for example. Firewalls perform > permit/deny; they don’t proxy. Likewise with IDS/IPS. Etc. Etc. > Shouldn’t we assume that service chains will consist of proxying and > non-proxying kinds? Besides, I don’t read that the draft requires > proxying, do you? > > I’m not saying service function nodes can’t partake in SFC > implementations—no need to stifle innovation. But do we need to require > that service function nodes MUST understand SFC headers, for example? > What happens to those that don’t? Are they all legacy? For many users > who have invested in non-SFC-understanding equipment, that’s practically > a non-starter. And it will likely slow adoption, IMO. > > Regards, > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 21 April 2014 6:22 PM > To: Zarny, Myo [Tech]; 'sfc@ietf.org' > Subject: Re: [sfc] Call for adoption of > draft-haeffner-sfc-use-case-mobility-01 > > I would prefer not to state that as a requirement. > > Where practical, we do indeed want (even need) to support existing > service funciton implementations. > > But there will be some service functions which can not be proxied and > which can not be placed into the middle of service chains. Trying to > solve 100% of the cases, if possible at all, will likely dramatically > slow the work down. > > Yours, > > Joel M. Halpern > > On 4/21/14, 6:03 PM, Zarny, Myo wrote: > >> I like the requirements listed in 3.1.2. > >> > >> Shouldn’t we also call this out? > >> > >> ·SFC solutions SHOULD not require any service functions to participate > >> in the implementation of SFCs. > >> > >> That is, service function nodes (LBs, proxys, FWs, etc.) need not > >> understand anything about SFCs; they could just be performing as they > >> are today. We could have service functions that partake in SFC > >> implementations but they don’t need to be required to. > >> > >> Regards, > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > >> (jguichar) > >> *Sent:* 18 April 2014 6:30 PM > >> *To:*sfc@ietf.org > >> *Subject:* [sfc] Call for adoption of > >> draft-haeffner-sfc-use-case-mobility-01 > >> > >> Dear WG: > >> > >> This message begins a two week call for WG adoption of the document > >>http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt > >> ending 2nd May 2014. > >> > >> Please respond to the SFC mailing list with any statements of approval > >> or disapproval. > >> > >> 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. Therefore, 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 them. > >> > >> > >> > >> _______________________________________________ > >> sfc mailing list > >>sfc@ietf.org > >>https://www.ietf.org/mailman/listinfo/sfc > >> > From nobody Tue Apr 22 08:38:18 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 AD7481A0684 for ; Tue, 22 Apr 2014 08:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.173 X-Spam-Level: X-Spam-Status: No, score=-7.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 asekASceOxnx for ; Tue, 22 Apr 2014 08:38:11 -0700 (PDT) Received: from mxecd05.gs.com (mxe1.gs.com [204.4.187.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6C1A0677 for ; Tue, 22 Apr 2014 08:38:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,904,1389762000"; d="scan'208";a="43756892" Received: from unknown (HELO mxpbd01-public.ny.fw.gs.com) ([148.86.115.129]) by mxecd05.idz.gs.com with ESMTP; 22 Apr 2014 11:38:05 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp04ex.firmwide.corp.gs.com ([10.135.172.74]) by mxpbd01.ny.fw.gs.com with ESMTP; 22 Apr 2014 11:38:04 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp04ex.firmwide.corp.gs.com ([10.135.172.74]) with mapi; Tue, 22 Apr 2014 11:38:04 -0400 To: "'Joel M. Halpern'" , "'sfc@ietf.org'" Date: Tue, 22 Apr 2014 11:38:02 -0400 Thread-Topic: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: Ac9eNpi3sfAc0zsLSXaDreBwagEeEAACGzYQ Message-ID: References: <53567B97.6020205@joelhalpern.com> In-Reply-To: <53567B97.6020205@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pKEK9C9kQWvEkOJ9Koc2AH-Z-to Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 22 Apr 2014 15:38:16 -0000 WW91IG1lYW4gU0ZDIHByb3hpZXMsIEkgc2VlLiBUaGF0IGNsZWFycyB1cCBhIGxvdC4NCg0KSSdt IG5vdCBwcm9wb3NpbmcgdGhhdCBhbGwgU0ZzIE5PVCBzdXBwb3J0IFNGQyBjYXBhYmlsaXRpZXMg YnV0IHRoYXQgdGhleSBub3QgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGVtLiBJdCBtYXkgYmUs IGFzIHlvdSBwb2ludCBvdXQsIHRoYXQgU0ZDIHNvbHV0aW9ucyBhcmUgc2ltcGxlciBpZiBTRnMg cGFydGljaXBhdGUgaW4gdGhlIGNoYWluIGltcGxlbWVudGF0aW9uLiBCdXQgc2hvdWxkbid0IHdl IGFsc28gYWxsb3cgZm9yIFNGQyBzb2x1dGlvbnMgdGhhdCBkb24ndCByZXF1aXJlIFNGcyB0byBw YXJ0aWNpcGF0ZT8gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGNsb3NlIHRoZSBkb29yIG9uIHRo YXQgaW4gdGhpcyB1c2UgY2FzZXMgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogMjIgQXByaWwgMjAxNCAxMDoyNCBB TQ0KVG86IFphcm55LCBNeW8gW1RlY2hdOyAnc2ZjQGlldGYub3JnJw0KU3ViamVjdDogUmU6IFtz ZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWhhZWZmbmVyLXNmYy11c2UtY2FzZS1tb2Jp bGl0eS0wMQ0KDQpZb3UgYXNrZWQgZm9yIGFuIGFkZGVkIHJlcXVpcmVtZW50IHRoYXQgU0ZDIFNI T1VMRCBub3QgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byBhbiBTRiBmb3IgaXQgdG8gYmUgdXNlZCBp biBTRkMgc2VydmljZSBjaGFpbmluZy4NCg0KV2hpbGUgYSBkZXNpcmFibGUgZ29hbCwgSSBleHBy ZXNzZWQgY29uY2VybiBhYm91dCBpdCBhcyBhIHJlcXVpcmVtZW50Lg0KTXkgcG9pbnQgaXMgdGhh dCBzdHJ1Y3R1cmluZyBTRkMgc28gdGhhdCBhbGwgZXhpc3RpbmcgYXBwbGljYXRpb25zIHdpbGwg d29yayB3aXRoIGl0IGFkZHMgc2lnbmlmaWNhbnQgY29tcGxleGl0eSB0byBTRkMuICBTZXR0bGlu ZyBmb3IgODAlIChvciA5MCUgaWYgd2UgY2FuKSBjb3ZlcmFnZSwgYW5kIHJlY29nbml6aW5nIHRo YXQgc29tZSBhcHBsaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGJlIGNoYW5nZSB0byBiZSB1c2VkIGFz IHNlcnZpY2UgZnVuY3Rpb25zIGluIFNGQywgd2lsbCBtYWtlIG91ciBqb2IgYWNoaWV2YWJsZS4N Cg0KV2UgY2FuIHVzZSBjaGFpbiBwcm94aWVzIGluIFNGQyB0byBlbmFibGUgbWFueSBleGlzdGlu ZyBhcHBsaWNhdGlvbnMgdG8gYmUgdXNlZCBpbiBTRkMgd2l0aG91dCBtb2RpZmljYXRpb24uICBU aGlzIHdhcyBhbiBleGFtcGxlIG9mIGEgdG9vbCB3ZSBhcmUgbGlrZWx5IHRvIG5lZWQgdG8gdXNl IHRvIGdldCBldmVuIDgwJSBjb3ZlcmFnZS4gIFNvIEkgbWVudGlvbmVkIGl0IHRvIGJlIGNsZWFy IHRoYXQgSSB3YXMgbm90IHRyeWluZyB0byBleGNsdWRlIHRoYXQgZnJvbSBvdXIgd29yay4NCg0K SSBkaWQgbm90IHRyeSB0byBpdGVtaXplIHdoYXQgYXBwbGljYXRpb25zIHdvdWxkIG5vdCBiZSBz dXBwb3J0ZWQuICBJIGhvcGUgdGhhdCB0aGUgbnVtYmVyIG9mIHRob3NlIGlzIHNtYWxsLiAgQnV0 IHdlIHdpbGwgZmluZCBvdXQgZG93biB0aGUgcm9hZC4NCg0KWW91cnMsDQpKb2VsDQoNClBTOiBJ dCBpcyBhbHdheXMgZGlmZmljdWx0IGZvciByZWFkZXJzIHRvIGJlIHN1cmUgd2hhdCB3ZSBpbnRl bmQgd2hlbiB3ZSBwdXQgYSAic2hvdWxkIiBpbiBhIHJlcXVpcmVtZW50cyBkb2N1bWVudC4NCg0K T24gNC8yMi8xNCwgOTo1MiBBTSwgWmFybnksIE15byB3cm90ZToNCj4gSSBmZWVsIGxpa2UgdGhl IHByb3h5aW5nIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQgaXMgZm9yIHNvbWUgb3RoZXIgU0ZDIA0K PiBwYXJ0aWNpcGF0aW5nL2VuYWJsaW5nIG5vZGVzLg0KPg0KPiBNeSBvcmlnaW5hbCBjb21tZW50 IHdhcyBvbiAvc2VydmljZSBmdW5jdGlvbiBub2Rlcy8gKGxpa2UgRldzLCBMQnMpLCANCj4gbm90 IFNGQyBlbmFibGluZyBub2RlcyBsaWtlIGZvcndhcmRpbmcgb3IgY2xhc3NpZmljYXRpb24gbm9k ZXMuIEFzIGZhciANCj4gYXMgSSBjYW4gc2VlLCB0aGUgZHJhZnQgZG9lc27igJl04oCUY29ycmVj dGx5IElNT+KAlHJlcXVpcmUg4oCccHJveHlpbmfigJ0gDQo+IHNlcnZpY2UgZnVuY3Rpb25zIG9u bHkgKHNpbmNlIGl0IGluY2x1ZGVzIGZpcmV3YWxscyBhcyBvbmUgb2YgdGhlIA0KPiBwb3NzaWJs ZSBzZXJ2aWNlIGZ1bmN0aW9ucykuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+ICpGcm9tOipKbWguZGly ZWN0IFttYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQo+ICpTZW50OiogMjEgQXBy aWwgMjAxNCA3OjM2IFBNDQo+ICpUbzoqIFphcm55LCBNeW8gW1RlY2hdOyBqbWhAam9lbGhhbHBl cm4uY29tOyBzZmNAaWV0Zi5vcmcNCj4gKlN1YmplY3Q6KiBSRTogW3NmY10gQ2FsbCBmb3IgYWRv cHRpb24gb2YNCj4gZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmlsaXR5LTAxDQo+ICpJ bXBvcnRhbmNlOiogTG93DQo+DQo+IFdpdGhvdXQgc29tZSBmaXJtIG9mIHByb3h5IGFueSBleGlz dGluZyBmdW5jdGlvbiB3aWxsLCBpZiB1c2VkIGluIHNmYywgDQo+IGxvc2UgdGdlIHRyYW5zcG9y dCBoZWFkZXIgYW5kIHRoZSBzZmMgc3BlY2lmaWMgaGVhZGVyLg0KPg0KPiBZb3VycywNCj4NCj4g Sm9lbA0KPg0KPg0KPiBTZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFydHBob25lIG9uIEFUJlQNCj4N Cj4NCj4NCj4NCj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPiBTdWJqZWN0 OiBSRTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YNCj4gZHJhZnQtaGFlZmZuZXItc2ZjLXVz ZS1jYXNlLW1vYmlsaXR5LTAxDQo+IEZyb206ICJaYXJueSwgTXlvIiA8TXlvLlphcm55QGdzLmNv bSA8bWFpbHRvOk15by5aYXJueUBncy5jb20+Pg0KPiBUbzogIidKb2VsIE0uIEhhbHBlcm4nIiA8 am1oQGpvZWxoYWxwZXJuLmNvbSANCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sIidz ZmNAaWV0Zi5vcmcnIiA8c2ZjQGlldGYub3JnIA0KPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ IENDOg0KPg0KPiBIaSBKb2VsLA0KPg0KPiBOb3Qgc3VyZSBhYm91dCB0aGUgY29tbWVudCBhYm91 dCB0aGUgbmVlZCBmb3IgcHJveHlpbmcgYXMgYSANCj4gcmVxdWlyZW1lbnQgZm9yIFNGQy4gTm90 IGFsbCBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgb2YgcHJveHlpbmcga2luZC4gDQo+IEV2ZW4gbG9h ZCBiYWxhbmNlcnMgZG9uJ3QgaGF2ZSB0byBwcm94eS0tRFNSIGZvciBleGFtcGxlLiBGaXJld2Fs bHMgDQo+IHBlcmZvcm0gcGVybWl0L2Rlbnk7IHRoZXkgZG9u4oCZdCBwcm94eS4gTGlrZXdpc2Ug d2l0aCBJRFMvSVBTLiBFdGMuIEV0Yy4NCj4gU2hvdWxkbuKAmXQgd2UgYXNzdW1lIHRoYXQgc2Vy dmljZSBjaGFpbnMgd2lsbCBjb25zaXN0IG9mIHByb3h5aW5nIGFuZCANCj4gbm9uLXByb3h5aW5n IGtpbmRzPyBCZXNpZGVzLCBJIGRvbuKAmXQgcmVhZCB0aGF0IHRoZSBkcmFmdCByZXF1aXJlcyAN Cj4gcHJveHlpbmcsIGRvIHlvdT8NCj4NCj4gSeKAmW0gbm90IHNheWluZyBzZXJ2aWNlIGZ1bmN0 aW9uIG5vZGVzIGNhbuKAmXQgcGFydGFrZSBpbiBTRkMgDQo+IGltcGxlbWVudGF0aW9uc+KAlG5v IG5lZWQgdG8gc3RpZmxlIGlubm92YXRpb24uIEJ1dCBkbyB3ZSBuZWVkIHRvIA0KPiByZXF1aXJl IHRoYXQgc2VydmljZSBmdW5jdGlvbiBub2RlcyBNVVNUIHVuZGVyc3RhbmQgU0ZDIGhlYWRlcnMs IGZvciBleGFtcGxlPw0KPiBXaGF0IGhhcHBlbnMgdG8gdGhvc2UgdGhhdCBkb27igJl0PyBBcmUg dGhleSBhbGwgbGVnYWN5PyBGb3IgbWFueSB1c2VycyANCj4gd2hvIGhhdmUgaW52ZXN0ZWQgaW4g bm9uLVNGQy11bmRlcnN0YW5kaW5nIGVxdWlwbWVudCwgdGhhdOKAmXMgDQo+IHByYWN0aWNhbGx5 IGEgbm9uLXN0YXJ0ZXIuIEFuZCBpdCB3aWxsIGxpa2VseSBzbG93IGFkb3B0aW9uLCBJTU8uDQo+ DQo+IFJlZ2FyZHMsDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpv ZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IFNlbnQ6IDIxIEFw cmlsIDIwMTQgNjoyMiBQTQ0KPiBUbzogWmFybnksIE15byBbVGVjaF07ICdzZmNAaWV0Zi5vcmcn DQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBhZG9wdGlvbiBvZg0KPiBkcmFmdC1oYWVm Zm5lci1zZmMtdXNlLWNhc2UtbW9iaWxpdHktMDENCj4NCj4gSSB3b3VsZCBwcmVmZXIgbm90IHRv IHN0YXRlIHRoYXQgYXMgYSByZXF1aXJlbWVudC4NCj4NCj4gV2hlcmUgcHJhY3RpY2FsLCB3ZSBk byBpbmRlZWQgd2FudCAoZXZlbiBuZWVkKSB0byBzdXBwb3J0IGV4aXN0aW5nIA0KPiBzZXJ2aWNl IGZ1bmNpdG9uIGltcGxlbWVudGF0aW9ucy4NCj4NCj4gQnV0IHRoZXJlIHdpbGwgYmUgc29tZSBz ZXJ2aWNlIGZ1bmN0aW9ucyB3aGljaCBjYW4gbm90IGJlIHByb3hpZWQgYW5kIA0KPiB3aGljaCBj YW4gbm90IGJlIHBsYWNlZCBpbnRvIHRoZSBtaWRkbGUgb2Ygc2VydmljZSBjaGFpbnMuICBUcnlp bmcgdG8gDQo+IHNvbHZlIDEwMCUgb2YgdGhlIGNhc2VzLCBpZiBwb3NzaWJsZSBhdCBhbGwsIHdp bGwgbGlrZWx5IGRyYW1hdGljYWxseSANCj4gc2xvdyB0aGUgd29yayBkb3duLg0KPg0KPiBZb3Vy cywNCj4NCj4gSm9lbCBNLiBIYWxwZXJuDQo+DQo+IE9uIDQvMjEvMTQsIDY6MDMgUE0sIFphcm55 LCBNeW8gd3JvdGU6DQo+DQo+PiBJIGxpa2UgdGhlIHJlcXVpcmVtZW50cyBsaXN0ZWQgaW4gMy4x LjIuDQo+DQo+Pg0KPg0KPj4gU2hvdWxkbuKAmXQgd2UgYWxzbyBjYWxsIHRoaXMgb3V0Pw0KPg0K Pj4NCj4NCj4+IMK3U0ZDIHNvbHV0aW9ucyBTSE9VTEQgbm90IHJlcXVpcmUgYW55IHNlcnZpY2Ug ZnVuY3Rpb25zIHRvIA0KPj4gcGFydGljaXBhdGUNCj4NCj4+IGluIHRoZSBpbXBsZW1lbnRhdGlv biBvZiBTRkNzLg0KPg0KPj4NCj4NCj4+IFRoYXQgaXMsIHNlcnZpY2UgZnVuY3Rpb24gbm9kZXMg KExCcywgcHJveHlzLCBGV3MsIGV0Yy4pIG5lZWQgbm90DQo+DQo+PiB1bmRlcnN0YW5kIGFueXRo aW5nIGFib3V0IFNGQ3M7IHRoZXkgY291bGQganVzdCBiZSBwZXJmb3JtaW5nIGFzIHRoZXkNCj4N Cj4+IGFyZSB0b2RheS4gV2UgY291bGQgaGF2ZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IHBhcnRh a2UgaW4gU0ZDDQo+DQo+PiBpbXBsZW1lbnRhdGlvbnMgYnV0IHRoZXkgZG9u4oCZdCBuZWVkIHRv IGJlIHJlcXVpcmVkIHRvLg0KPg0KPj4NCj4NCj4+IFJlZ2FyZHMsDQo+DQo+Pg0KPg0KPj4gKkZy b206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKaW0g R3VpY2hhcmQNCj4NCj4+IChqZ3VpY2hhcikNCj4NCj4+ICpTZW50OiogMTggQXByaWwgMjAxNCA2 OjMwIFBNDQo+DQo+PiAqVG86KnNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4N Cj4+ICpTdWJqZWN0OiogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YNCj4NCj4+IGRyYWZ0LWhh ZWZmbmVyLXNmYy11c2UtY2FzZS1tb2JpbGl0eS0wMQ0KPg0KPj4NCj4NCj4+IERlYXIgV0c6DQo+ DQo+Pg0KPg0KPj4gVGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNhbGwgZm9yIFdHIGFk b3B0aW9uIG9mIHRoZSBkb2N1bWVudA0KPg0KPj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWhhZWZmbmVyLXNmYy11c2UtY2FzZS1tb2JpbGl0eS0wMS50eHQNCj4NCj4+IGVuZGluZyAybmQg TWF5IDIwMTQuDQo+DQo+Pg0KPg0KPj4gUGxlYXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5n IGxpc3Qgd2l0aCBhbnkgc3RhdGVtZW50cyBvZiANCj4+IGFwcHJvdmFsDQo+DQo+PiBvciBkaXNh cHByb3ZhbC4NCj4NCj4+DQo+DQo+PiBQbGVhc2Ugbm90ZToNCj4NCj4+DQo+DQo+PiAxLlRoaXMg aXMgbm90IFdHIExhc3QgQ2FsbC4gVGhlIGRvY3VtZW50IGlzIG5vdCBmaW5hbCwgYW5kIHRoZSBX RyBpcw0KPg0KPj4gZXhwZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1bWVudOKAmXMgY29udGVudCB1 bnRpbCB0aGVyZSBpcyBXRyBjb25zZW5zdXMNCj4NCj4+IHRoYXQgdGhlIGNvbnRlbnQgaXMgc29s aWQuIFRoZXJlZm9yZSwgcGxlYXNlIGRvbuKAmXQgb3Bwb3NlIGFkb3B0aW9uDQo+DQo+PiBqdXN0 IGJlY2F1c2UgeW91IHdhbnQgdG8gc2VlIGNoYW5nZXMgdG8gaXRzIGNvbnRlbnQuDQo+DQo+Pg0K Pg0KPj4gMi5JZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVu dCwgcGxlYXNlIHN0YXRlDQo+DQo+PiB5b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0 IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIGNvbmNlcm5zLg0KPg0KPj4NCj4NCj4+IDMu SWYgeW91IGhhdmUgaXNzdWVzIHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0 aG9zZSANCj4+IGlzc3Vlcw0KPg0KPj4gYW5kIHdlIGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91dCBo b3cgYmVzdCB0byBhZGRyZXNzIHRoZW0uDQo+DQo+Pg0KPg0KPj4NCj4NCj4+DQo+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPj4gc2ZjIG1h aWxpbmcgbGlzdA0KPg0KPj5zZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+DQo+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+Pg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxp bmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0K From nobody Tue Apr 22 10:54: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 7A67B1A06A7 for ; Tue, 22 Apr 2014 10:54:51 -0700 (PDT) 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 mOHIHKp_aJMP for ; Tue, 22 Apr 2014 10:54:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA931A06AB for ; Tue, 22 Apr 2014 10:54:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 193AC240929 for ; Tue, 22 Apr 2014 10:54:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D0DEF2408DC for ; Tue, 22 Apr 2014 10:54:39 -0700 (PDT) Message-ID: <5356ACDA.3090709@joelhalpern.com> Date: Tue, 22 Apr 2014 13:54:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "sfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eMOaYlgQ9rQosfWHa-qPtnkIKC8 Subject: [sfc] Use Case drafts and requirements 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, 22 Apr 2014 17:54:51 -0000 Myo Zarny pointed something out to me that I had overlooked. The mobility use case draft has requirements buried in it. Distributing requirements across multiple drafts is a bad practice. And tying requirements to the use case drafts is confusing. As I understand it, we are adopting use cases as guidance, not as requirements. They are cases we want to support. Requirements should be derived from them, not included in them. Thus, I would ask that as part of adopting this draft, or in a respin shortly thereafter, the material in section 3.1.2 be removed for later discussion in a requirements draft. Yours, Joel PS: Don't ask how I missed the clear section in my earlier reading. Sorry. From nobody Tue Apr 22 14:05: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 A97A51A0271 for ; Tue, 22 Apr 2014 14:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] 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 fr42jt2xOHKz for ; Tue, 22 Apr 2014 14:05:35 -0700 (PDT) Received: from mailout09.vodafone.com (mailout09.vodafone.com [195.232.224.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A91A025D for ; Tue, 22 Apr 2014 14:05:35 -0700 (PDT) Received: from mailint09.vodafone.com (localhost [127.0.0.1]) by mailout09.vodafone.com (Postfix) with ESMTP id 1A0A3E1959 for ; Tue, 22 Apr 2014 23:05:29 +0200 (CEST) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09.vodafone.com (Postfix) with ESMTPS id 0D0BDE12A9; Tue, 22 Apr 2014 23:05:29 +0200 (CEST) Received: from VOEXM20W.internal.vodafone.com ([169.254.4.32]) by VOEXC05W.internal.vodafone.com ([145.230.101.25]) with mapi id 14.03.0146.002; Tue, 22 Apr 2014 23:05:28 +0200 From: "Haeffner, Walter, Vodafone DE" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Use Case drafts and requirements Thread-Index: AQHPXlP7rY1muKa5P0qKOVZ82pX455seGVyQ Date: Tue, 22 Apr 2014 21:05:28 +0000 Message-ID: References: <5356ACDA.3090709@joelhalpern.com> In-Reply-To: <5356ACDA.3090709@joelhalpern.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iPi3uAlxymGHU2CQvmby4ZSvfrQ Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Use Case drafts and requirements 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, 22 Apr 2014 21:05:40 -0000 Hi Joel, Thanks for your remark. Sounds reasonable. Will discuss issue with co-autho= rs. Original intension was to mention weak points in typical current SFC im= plementations. Hope you are fine with this. From there it was only a small = further step to end with requirements.=20 For me it is OK to collect all requirements derived from all use case draf= ts finally in a separate draft. Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern Gesendet: Dienstag, 22. April 2014 19:55 An: sfc@ietf.org Betreff: [sfc] Use Case drafts and requirements Myo Zarny pointed something out to me that I had overlooked. The mobility use case draft has requirements buried in it. Distributing requirements across multiple drafts is a bad practice. And tying requirements to the use case drafts is confusing. As I understan= d it, we are adopting use cases as guidance, not as requirements. They are= cases we want to support. Requirements should be derived from them, not i= ncluded in them. Thus, I would ask that as part of adopting this draft, or in a respin short= ly thereafter, the material in section 3.1.2 be removed for later discussio= n in a requirements draft. Yours, Joel PS: Don't ask how I missed the clear section in my earlier reading. Sorry. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 22 14:20: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 9E55B1A026B for ; Tue, 22 Apr 2014 14:20:14 -0700 (PDT) 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 h3Ny6D2CQWB1 for ; Tue, 22 Apr 2014 14:20:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6E1A025D for ; Tue, 22 Apr 2014 14:20:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 032722403BB; Tue, 22 Apr 2014 14:20:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8E8D824012B; Tue, 22 Apr 2014 14:20:04 -0700 (PDT) Message-ID: <5356DCFE.3080401@joelhalpern.com> Date: Tue, 22 Apr 2014 17:19:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Haeffner, Walter, Vodafone DE" , "sfc@ietf.org" References: <5356ACDA.3090709@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qWsfCDLF9tU9hlYBzfEPmXEVg-E Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Use Case drafts and requirements 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, 22 Apr 2014 21:20:14 -0000 Noting ways that existing solutions have trouble with the use cass is probably useful in the use case document, even if atypical. Part of my concern is that I don't want to get caught in trying to wordsmith requirements text (which need careful wording) when our goal is to get the point that the overall behavior is needed. Yours, Joel On 4/22/14, 5:05 PM, Haeffner, Walter, Vodafone DE wrote: > Hi Joel, > > Thanks for your remark. Sounds reasonable. Will discuss issue with co-authors. Original intension was to mention weak points in typical current SFC implementations. Hope you are fine with this. From there it was only a small further step to end with requirements. > > For me it is OK to collect all requirements derived from all use case drafts finally in a separate draft. > > Regards, Walter > > -----Ursprüngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern > Gesendet: Dienstag, 22. April 2014 19:55 > An: sfc@ietf.org > Betreff: [sfc] Use Case drafts and requirements > > Myo Zarny pointed something out to me that I had overlooked. > The mobility use case draft has requirements buried in it. > Distributing requirements across multiple drafts is a bad practice. > And tying requirements to the use case drafts is confusing. As I understand it, we are adopting use cases as guidance, not as requirements. They are cases we want to support. Requirements should be derived from them, not included in them. > > Thus, I would ask that as part of adopting this draft, or in a respin shortly thereafter, the material in section 3.1.2 be removed for later discussion in a requirements draft. > > Yours, > Joel > > PS: Don't ask how I missed the clear section in my earlier reading. Sorry. > > _______________________________________________ > 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 nobody Wed Apr 23 00:06: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 6CD6F1A0088; Wed, 23 Apr 2014 00:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.477 X-Spam-Level: * X-Spam-Status: No, score=1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 6QKePLDpmMAZ; Wed, 23 Apr 2014 00:06:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAE821A00A7; Wed, 23 Apr 2014 00:06:40 -0700 (PDT) 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 BDJ94774; Wed, 23 Apr 2014 07:06:33 +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; Wed, 23 Apr 2014 08:05:38 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 08:06:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 23 Apr 2014 15:06:22 +0800 From: "Songhaibin (A)" To: Robert Raszuk , Xuxiaohu Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogV2h5IFRyYW5zcG9ydCBEZXBlbmRlbmNlIGlzIGRlZW1l?= =?gb2312?B?ZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1z?= =?gb2312?Q?fc-problem-statement-04.txt?= Thread-Index: AQHPXf1eQcMxCFyktUu1W9GbAFmBf5sextVg Date: Wed, 23 Apr 2014 07:06:21 +0000 Message-ID: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-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.109] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XWO1oc3XNYHTgNuQ1bEuSyG6VZg Cc: "spring@ietf.org" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] =?gb2312?b?tPC4tDogV2h5IFRyYW5zcG9ydCBEZXBlbmRlbmNlIGlzIGRl?= =?gb2312?b?ZW1lZCBhcyBhIHByb2JsZW0/Ly9yZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0?= =?gb2312?b?Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0?= 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, 23 Apr 2014 07:06:46 -0000 SGksDQoNCg0KIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KPiBTZW50 OiBUdWVzZGF5LCBBcHJpbCAyMiwgMjAxNCAzOjI4IFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzog c3ByaW5nQGlldGYub3JnOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtzZmNdILTwuLQ6IFdoeSBUcmFuc3BvcnQgRGVwZW5kZW5jZSBpcyBkZWVtZWQgYXMgYQ0KPiBw cm9ibGVtPy8vcmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50 LTA0LnR4dA0KPiANCj4gPiBbWGlhb2h1XSBZb3VyIG9ic2VydmF0aW9uIGlzIGNvcnJlY3QuIFRo ZSBTRiBwcm94eSBtdXN0IHN0cmlwIHRoZSBOU0gNCj4gPiBhbmQgdGhlDQo+IFNSIGhlYWRlciBi ZWZvcmUgc2VuZGluZyB0aGUgcGFja2V0cyB0byB0aGUgZGlyZWN0bHkgYXR0YWNoZWQgbGVnYWN5 IHNlcnZpY2UNCj4gZnVuY3Rpb25zLiBXaGVuIHRoZSBwYWNrZXRzIHdhcyByZXR1cm5lZCBieSBz ZXJ2aWNlIGZ1bmN0aW9ucywgdGhlIFNGIHByb3h5DQo+IG11c3QgcmVpbXBvc2UgdGhvc2UgaGVh ZGVycyBvbiB0aGUgcGFja2V0cy4gTWVhbndoaWxlLCB0aGUgU0YgcHJveHkgbXVzdA0KPiBkZWNy ZWFzZSB0aGUgc2VydmljZSBpbmRleCB2YWx1ZSBieSAxLg0KPiA+DQo+IA0KPiBHb29kIHNvIHdl IGFncmVlIG9uIHRoYXQgcG9pbnQuDQo+IA0KPiBXaGF0IGFjdHVhbGx5IHdvcnJpZXMgbWUgYSBi aXQgdGhhdCB0byAicmVpbXBvc2UiIHlvdSBuZWVkIHRvIGRvIGZ1bGwNCj4gY2xhc3NpZmljYXRp b24gYWdhaW4gLSBqdXN0IGxpa2UgeW91IGRvIGl0IG9uIGFsbCBpbmdyZXNzIG5vZGVzLg0KPiAN Cj4gTW9yZW92ZXIgaG93IHlvdSByZWltcG9zZSBjb3VsZCBiZSBhbHNvIGEgZnVuY3Rpb24gb2Yg c2VydmljZSBwcm9kdWN0Lg0KDQpBY3R1YWxseSB3ZSBoYXZlIGEgZHJhZnQgdG8gdGFsayBhYm91 dCB0aGUgbGVnYWN5IHN1cHBvcnQuIEZpcnN0LCB0aGluZ3MgaGF2ZSB0byBiZSBjbGFzc2lmaWVk IGFjY29yZGluZyB0byB3aGV0aGVyIHRoZSBsZWdhY3kgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5j ZSBpcyB0cmFuc3BhcmVudCBvciBub3QuIFRoZW4gaWYgaXQgaXMgdHJhbnNwYXJlbnQsIHlvdSBj YW4gdXNlIGRpZmZlcmVudCBmaWVsZHMgaW4gdGhlIHBhY2tldCB0byBtYXAgdG8gc2VydmljZSBo ZWFkZXIgYW5kIHRoZW4gcmV0cmlldmFsIGl0IGFnYWluLiBJZiBub3QsIHRoaW5ncyBiZWNvbWUg bXVjaCBtb3JlIGNvbXBsaWNhdGVkLiBIZXJlIGlzIHRoZSBsaW5rIGZvciB0aGUgZHJhZnQuDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zb25nLXNmYy1sZWdhY3ktc2Yt bWFwcGluZy8NCg0KQlIsDQotSGFpYmluDQoNCj4gDQo+IA0KPiA+DQo+ID4gVGhhdCBhY3R1YWxs eSBtZWFucyB0aGF0IG5ldHdvcmsgbmVlZHMgdG8gY2FycnkgdGhlIHN0YXRlIHByZXR0eSBtdWNo IG91dCBvZg0KPiBiYW5kLiBTdWNoIHN0YXRlIGNvdWxkIGJlIGNhcnJpZWQgd2l0aGluIHJvdXRp bmcgcHJvdG9jb2xzICh0b2RheSBCR1AgaXMgdXNlZA0KPiBmb3IgdGhhdCBpbiBMM1ZQTiBjYXNl KSBvciBieSBuZXcgb3ZlcmxheSBjb250cm9sIHBsYW5lIC0gc2FtZSBhcyBpcyB1c2VkIHRvDQo+ IGNhcnJ5IHRoZSBtZXRhZGF0YS4NCj4gPg0KPiA+DQo+ID4gW1hpYW9odV0gRGlkIHlvdSBtZWFu IHRoYXQgdGhlIG1ldGFkYXRhIHNob3VsZCBiZSB0cmFuc2ZlcnJlZCB0aHJvdWdoIHRoZQ0KPiBj b250cm9sIHBsYW5lPw0KPiANCj4gDQo+IEhvdyBlbHNlIHdvdWxkIHlvdSBjYXJyeSBpdCA/IEl0 J3Mgbm90IGRhdGEgcGxhbmUgYWZ0ZXIgYWxsLiBPZiBjb3Vyc2UgcGVyaGFwcw0KPiB5b3VyIGRl ZmluaXRpb24gb2YgY29udHJvbCBwbGFuZSA9IHJvdXRpbmcgcHJvdG9jb2xzLCBidXQgSSBkaWQg bm90IG1lYW4gdGhhdC4NCj4gDQo+IENvbnRyb2wgcGxhbmUgaXMganVzdCBhIGluZm9ybWF0aW9u IG92ZXJsYXkgb2Ygc29tZSBmb3JtLiBKdXN0IGxpa2UgSU4gbmV0d29ya3MNCj4gaW4gd2VsbCBr bm93biB0ZWxlcGhvbmUgbmV0d29ya3MgOikNCj4gDQo+IENoZWVycywNCj4gUi4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWls aW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo= From nobody Wed Apr 23 01:20: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 34D511A010F; Wed, 23 Apr 2014 01:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 gjr6Iv8asWWF; Wed, 23 Apr 2014 01:19:53 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B29BC1A00CF; Wed, 23 Apr 2014 01:19:53 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id h18so4031247igc.7 for ; Wed, 23 Apr 2014 01:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=u9H1KZ1I6wOUeKUQS+sBg8hIDGc4q3y3PXO31aCi0FE=; b=IjAJfu6T7l0d3Tz4qOUDxeab6mvOhxqFNzbPPDG9hE3xgoXVivcr09hyPT+6nlHz1D 4YYWJAfdvr4rMqX+WSQQiIVhWDOv/dcmQUSl1F24olNwdVeSSb2hXaiJhNP4PzS7oubF igGjnzbHycPHzh1Keq6YF53cut4tohSAjUljW3DG37Vodo+Fq1Pcp6dlRiwdZgFYAnVD UmXdO6WQdG7eHx0n+z/0uQrT0XjtpGY33c6rFazhMxmZFSRrVAVmKWrSbkWoMlBTtgkp px7B9U2DkXFKEFYjkGE0bFtuttUp7UZmvKpn0YZDaHwhEbTecd158d2ZB2C02QkBCqQq Yn3g== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr857032igb.9.1398241188074; Wed, 23 Apr 2014 01:19:48 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 23 Apr 2014 01:19:47 -0700 (PDT) In-Reply-To: References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C163@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826C903@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826CCF9@NKGEML512-MBS.china.huawei.com> Date: Wed, 23 Apr 2014 10:19:47 +0200 X-Google-Sender-Auth: Pk3PbcGiqu8sLwkGxym1p2YLz5o Message-ID: From: Robert Raszuk To: "Songhaibin (A)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RFDHa9TMVQs7XRi8H6Zig5cm8Ec Cc: Ron Parker , Xuxiaohu , "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBXaHkgVHJhbnNwb3J0IERlcGVuZGVuY2UgaXMg?= =?utf-8?q?deemed_as_a_problem=3F//re=3A_I-D_Action=3A_draft-ietf-sfc-prob?= =?utf-8?q?lem-statement-04=2Etxt?= 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, 23 Apr 2014 08:19:58 -0000 Hi Haibin, Actually my comments were in regards to non transparent SF (your section 3.= 2). And honestly I am not consider those as legacy. IMO even modern service nodes should not be forced to "handle" SF headers. So much more focus should be made to make the solutions well understood as those directly have great impact on the entire network control plane side. Simply stating removing all the packet/flow state from the network is not possible. Cheers, R. On Wed, Apr 23, 2014 at 9:06 AM, Songhaibin (A) wr= ote: > Hi, > > > -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Robert Raszuk >> Sent: Tuesday, April 22, 2014 3:28 PM >> To: Xuxiaohu >> Cc: spring@ietf.org; Ron Parker; sfc@ietf.org >> Subject: Re: [sfc] =E7=AD=94=E5=A4=8D: Why Transport Dependence is deeme= d as a >> problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt >> >> > [Xiaohu] Your observation is correct. The SF proxy must strip the NSH >> > and the >> SR header before sending the packets to the directly attached legacy ser= vice >> functions. When the packets was returned by service functions, the SF pr= oxy >> must reimpose those headers on the packets. Meanwhile, the SF proxy must >> decrease the service index value by 1. >> > >> >> Good so we agree on that point. >> >> What actually worries me a bit that to "reimpose" you need to do full >> classification again - just like you do it on all ingress nodes. >> >> Moreover how you reimpose could be also a function of service product. > > Actually we have a draft to talk about the legacy support. First, things = have to be classified according to whether the legacy service function inst= ance is transparent or not. Then if it is transparent, you can use differen= t fields in the packet to map to service header and then retrieval it again= . If not, things become much more complicated. Here is the link for the dra= ft. > https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/ > > BR, > -Haibin > >> >> >> > >> > That actually means that network needs to carry the state pretty much = out of >> band. Such state could be carried within routing protocols (today BGP is= used >> for that in L3VPN case) or by new overlay control plane - same as is use= d to >> carry the metadata. >> > >> > >> > [Xiaohu] Did you mean that the metadata should be transferred through = the >> control plane? >> >> >> How else would you carry it ? It's not data plane after all. Of course p= erhaps >> your definition of control plane =3D routing protocols, but I did not me= an that. >> >> Control plane is just a information overlay of some form. Just like IN n= etworks >> in well known telephone networks :) >> >> Cheers, >> R. >> >> _______________________________________________ >> 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 nobody Wed Apr 23 13:25: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 688851A0646 for ; Wed, 23 Apr 2014 13:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 KjiufBRU9osK for ; Wed, 23 Apr 2014 13:25:48 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id E75731A0645 for ; Wed, 23 Apr 2014 13:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2676; q=dns/txt; s=iport; t=1398284742; x=1399494342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qC1W3J+ak4URPGB0RIMHrOKge+nQ/v6OFSTgllCLtFI=; b=OdfWbAhWlinJDWmZ+42r3Yvq2Pwht7l9Rp8brBQYgmO+rUflL82uvU3Y bXixyKpeiWesoCCSwaORinQRBOLWNw6DCGHyyt+N6DtyFB3iLkd3M0s4V APvjhY+9gE/Z16LWc1ani7DN536YfJm9o8zrIPVAZEvfGgGgCZEnE6A2t 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFALggWFOtJV2a/2dsb2JhbABagwZPV7x+hzqBHBZ0giUBAQEDAQEBAWsLBQsCAQgYJwcnCxQRAgQOBRuIHggNzhATBI11MDMHgySBFQSYdZJVgzGCKw X-IronPort-AV: E=Sophos;i="4.97,913,1389744000"; d="scan'208";a="38172013" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 23 Apr 2014 20:25:41 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3NKPfY1026646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 20:25:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.67]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 15:25:41 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Use Case drafts and requirements Thread-Index: AQHPXlP4k3HfEPF1OkKFkaiga48x25sedFYAgAAEDQCAAYMpAA== Date: Wed, 23 Apr 2014 20:25:41 +0000 Message-ID: <40BAF17F-2864-40B0-9458-859B43697E40@cisco.com> References: <5356ACDA.3090709@joelhalpern.com> <5356DCFE.3080401@joelhalpern.com> In-Reply-To: <5356DCFE.3080401@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.158.223] Content-Type: text/plain; charset="Windows-1252" Content-ID: <414996EEDDF45544914C564AEBAF9D3D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FFPi62ZD6epq8n8OUj3QG6L3Et0 Cc: "Haeffner, Walter, Vodafone DE" , "sfc@ietf.org" , "Jeffrey Napper \(jenapper\)" Subject: Re: [sfc] Use Case drafts and requirements 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, 23 Apr 2014 20:25:49 -0000 Hi Joel, I agree, getting caught up in a complex requirement doc (and associated lon= g drawn out process) is not something we need, want, nor are chartered for.= Rather, let=92s focus on clear use cases and use them to drive requiremen= ts. Thanks Paul On Apr 22, 2014, at 2:19 PM, Joel M. Halpern wrote: > Noting ways that existing solutions have trouble with the use cass is pro= bably useful in the use case document, even if atypical. >=20 > Part of my concern is that I don't want to get caught in trying to wordsm= ith requirements text (which need careful wording) when our goal is to get = the point that the overall behavior is needed. >=20 > Yours, > Joel >=20 > On 4/22/14, 5:05 PM, Haeffner, Walter, Vodafone DE wrote: >> Hi Joel, >>=20 >> Thanks for your remark. Sounds reasonable. Will discuss issue with co-au= thors. Original intension was to mention weak points in typical current SFC= implementations. Hope you are fine with this. From there it was only a sma= ll further step to end with requirements. >>=20 >> For me it is OK to collect all requirements derived from all use case d= rafts finally in a separate draft. >>=20 >> Regards, Walter >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern >> Gesendet: Dienstag, 22. April 2014 19:55 >> An: sfc@ietf.org >> Betreff: [sfc] Use Case drafts and requirements >>=20 >> Myo Zarny pointed something out to me that I had overlooked. >> The mobility use case draft has requirements buried in it. >> Distributing requirements across multiple drafts is a bad practice. >> And tying requirements to the use case drafts is confusing. As I unders= tand it, we are adopting use cases as guidance, not as requirements. They = are cases we want to support. Requirements should be derived from them, no= t included in them. >>=20 >> Thus, I would ask that as part of adopting this draft, or in a respin sh= ortly thereafter, the material in section 3.1.2 be removed for later discus= sion in a requirements draft. >>=20 >> Yours, >> Joel >>=20 >> PS: Don't ask how I missed the clear section in my earlier reading. Sor= ry. >>=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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 23 14:40:21 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 077911A06CE for ; Wed, 23 Apr 2014 14:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 0HpQ--13_VnZ for ; Wed, 23 Apr 2014 14:40:17 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 197D61A06CD for ; Wed, 23 Apr 2014 14:40:16 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id l4so1327189lbv.13 for ; Wed, 23 Apr 2014 14:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CZlCChVs/px3oUQcEYu9xddiMZ9rNfZe+JqAD3AhpHg=; b=GhC4ZbW3YlN8NSn5twX9b/KVJH5CI0sLWC1034yuC8R2D0I8vNZBBvqOHd+uEa3ep/ VEWn+FyvccZbG/IehcwdK366OQuUaGYn5VQrtAO4iSkKPGR4mUcUPdNXH8RkgV4gnXk5 fGYdrn8+bJGqpRBq27Rx605EUcX0pjYAPNQJUk1jD4bwgp7MHJmXimQWQDCDzV955Pi3 OHPmpOpzu9a/JxmEV4/XIr6IhQIbVcD1Q5xDFLS2ssJddGGqJmo/VruaxWXZnmIv6GK1 x/KkLQG7P9zRJi1lSAmjhco1uOyn6zTanzb7sObNqJZnXsnGb7fAcAkyNLsx/9H8cMT1 eFYw== MIME-Version: 1.0 X-Received: by 10.112.171.67 with SMTP id as3mr33367578lbc.10.1398289210668; Wed, 23 Apr 2014 14:40:10 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 23 Apr 2014 14:40:10 -0700 (PDT) In-Reply-To: <5356720A.4080302@joelhalpern.com> References: <20140421195656.18585.79150.idtracker@ietfa.amsl.com> <5356720A.4080302@joelhalpern.com> Date: Wed, 23 Apr 2014 16:40:10 -0500 Message-ID: From: Behcet Sarikaya To: "Joel M. Halpern" , sfc@ietf.org Content-Type: multipart/alternative; boundary=001a11c2620cb1fdcd04f7bc93a2 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WvOfLHm2F_tflw1ekOHrFPjSuXs Cc: Xueli Subject: Re: [sfc] I-D Action: draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 21:40:19 -0000 --001a11c2620cb1fdcd04f7bc93a2 Content-Type: text/plain; charset=UTF-8 Hi Joel, Thanks for your comments. I think you forgot to cc it to the list :-) On Tue, Apr 22, 2014 at 8:43 AM, Joel M. Halpern wrote: > Reading this, it appears that youa re asserting that service functions in > a service chain environment must be able to decrypt subscriber encrypted > https traffic. > > I agree that encryption makes applying content functions harder. > > But the IETF is not going to mandate operator based decryption of > end-to-end encrypted content. Doing so would seem to require that we > violate existing RFCs and weaken the effective crypto. For example, it is > simply not acceptable to require that customers accept operator > certificates in place of content provider certificates. (Some customers > may choose to accept those, but we clear can not mandate such.) > > In fact we carried this text from Broadband Forum Document SD-326 on flexible service chaining, Section 6.2.2. We did not intend to hint on an IETF solution. SD-326 also says that the solution is out of scope. > Separately, the content of the document does not seem to match the title. > Based on the title I was expecting to see a discussion of the problems > caused by address sharing. (Such problems are part of the motivation for > subscriber identification metadata.) But instead there is a description of > some use cases for residential network service, without any discussion I > could find of address sharing. What did I miss. > > I think the description is there but may be it needs to be clarified which we will do in the next version. Regards, Behcet > Yours, > Joel > > On 4/21/14, 3:56 PM, internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Host Identification Problem in Service >> Function Chaining Use Cases >> Authors : Li Xue >> Behcet Sarikaya >> Filename : draft-xue-sfc-address-sharing- >> in-sfc-use-cases-00.txt >> Pages : 7 >> Date : 2014-04-21 >> >> Abstract: >> The purpose of this document is to present host identification >> problem due to the address and prefix sharing in service function >> chaining. So far we have identified this problem in the two use >> cases of the parental control service and offloading service but it >> is likely that more use cases can be identified. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-xue-sfc-address- >> sharing-in-sfc-use-cases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-xue-sfc-address-sharing- >> in-sfc-use-cases-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 >> >> --001a11c2620cb1fdcd04f7bc93a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Thanks for your comments. I thi= nk you forgot to cc it to the list :-)

On Tue, Apr 22, 2014 at 8:43 AM, Joel M. Halpe= rn <jmh@joelhalpern.com> wrote:
Reading this, it appears that youa re assert= ing that service functions in a service chain environment must be able to d= ecrypt subscriber encrypted https traffic.

I agree that encryption makes applying content functions harder.

But the IETF is not going to mandate operator based decryption of end-to-en= d encrypted content. =C2=A0Doing so would seem to require that we violate e= xisting RFCs and weaken the effective crypto. =C2=A0For example, it is simp= ly not acceptable to require that customers accept operator certificates in= place of content provider certificates. =C2=A0(Some customers may choose t= o accept those, but we clear can not mandate such.)


In fact we carried this text from Broa= dband Forum Document SD-326 on flexible service chaining, Section 6.2.2.
We did not intend to hint on an IETF solution. SD-326 also says= that the solution is out of scope.
=C2=A0
Separately, the content of the document does not seem to match the title. = =C2=A0Based on the title I was expecting to see a discussion of the problem= s caused by address sharing. =C2=A0(Such problems are part of the motivatio= n for subscriber identification metadata.) =C2=A0But instead there is a des= cription of some use cases for residential network service, without any dis= cussion I could find of address sharing. =C2=A0What did I miss.


I think the description is there but m= ay be it needs to be clarified which we will do in the next version.
Regards,

Behcet
Yours,
Joel

On 4/21/14, 3:56 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Host Identification Problem in Service Function Chaining Use Cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Li = Xue
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Behcet Sarikaya
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-xue= -sfc-address-sharing-in-sfc-use-cases-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-04-21

Abstract:
=C2=A0 =C2=A0 The purpose of this document is to present host identificatio= n
=C2=A0 =C2=A0 problem due to the address and prefix sharing in service func= tion
=C2=A0 =C2=A0 chaining. =C2=A0So far we have identified this problem in the= two use
=C2=A0 =C2=A0 cases of the parental control service and offloading service = but it
=C2=A0 =C2=A0 is likely that more use cases can be identified.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-xue-sfc-address-sharing-in-sfc-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-xue= -sfc-address-sharing-in-sfc-use-cases-00


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@iet= f.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


--001a11c2620cb1fdcd04f7bc93a2-- From nobody Wed Apr 23 15:11: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 569F51A06D2 for ; Wed, 23 Apr 2014 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 9Hm07titfiwX for ; Wed, 23 Apr 2014 15:11:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3B1A06DC for ; Wed, 23 Apr 2014 15:11:49 -0700 (PDT) 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 BDK72450; Wed, 23 Apr 2014 22:11:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 23:10:46 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 23:11:42 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Wed, 23 Apr 2014 15:11:38 -0700 From: Lucy yong To: "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] Use Case drafts and requirements Thread-Index: AQHPXlQEQJKbFpKZVUi3wykgVjFkV5seld0AgAAEDQCAAYMqgP//p/5A Date: Wed, 23 Apr 2014 22:11:37 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45372DBC@dfweml701-chm.china.huawei.com> References: <5356ACDA.3090709@joelhalpern.com> <5356DCFE.3080401@joelhalpern.com> <40BAF17F-2864-40B0-9458-859B43697E40@cisco.com> In-Reply-To: <40BAF17F-2864-40B0-9458-859B43697E40@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.244] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mp4n6Zogein8ySi23XmNvuyjgQw Cc: "sfc@ietf.org" Subject: Re: [sfc] Use Case drafts and requirements 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, 23 Apr 2014 22:11:53 -0000 I support this approach! Cheers, Lucy=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Wednesday, April 23, 2014 3:26 PM To: Joel M. Halpern Cc: Haeffner, Walter, Vodafone DE; sfc@ietf.org; Jeffrey Napper (jenapper) Subject: Re: [sfc] Use Case drafts and requirements Hi Joel, I agree, getting caught up in a complex requirement doc (and associated lon= g drawn out process) is not something we need, want, nor are chartered for.= Rather, let's focus on clear use cases and use them to drive requirements= . Thanks Paul On Apr 22, 2014, at 2:19 PM, Joel M. Halpern wrote: > Noting ways that existing solutions have trouble with the use cass is pro= bably useful in the use case document, even if atypical. >=20 > Part of my concern is that I don't want to get caught in trying to wordsm= ith requirements text (which need careful wording) when our goal is to get = the point that the overall behavior is needed. >=20 > Yours, > Joel >=20 > On 4/22/14, 5:05 PM, Haeffner, Walter, Vodafone DE wrote: >> Hi Joel, >>=20 >> Thanks for your remark. Sounds reasonable. Will discuss issue with co-au= thors. Original intension was to mention weak points in typical current SFC= implementations. Hope you are fine with this. From there it was only a sma= ll further step to end with requirements. >>=20 >> For me it is OK to collect all requirements derived from all use case d= rafts finally in a separate draft. >>=20 >> Regards, Walter >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern >> Gesendet: Dienstag, 22. April 2014 19:55 >> An: sfc@ietf.org >> Betreff: [sfc] Use Case drafts and requirements >>=20 >> Myo Zarny pointed something out to me that I had overlooked. >> The mobility use case draft has requirements buried in it. >> Distributing requirements across multiple drafts is a bad practice. >> And tying requirements to the use case drafts is confusing. As I unders= tand it, we are adopting use cases as guidance, not as requirements. They = are cases we want to support. Requirements should be derived from them, no= t included in them. >>=20 >> Thus, I would ask that as part of adopting this draft, or in a respin sh= ortly thereafter, the material in section 3.1.2 be removed for later discus= sion in a requirements draft. >>=20 >> Yours, >> Joel >>=20 >> PS: Don't ask how I missed the clear section in my earlier reading. Sor= ry. >>=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 >=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 nobody Wed Apr 23 17:44: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 A00981A076F for ; Wed, 23 Apr 2014 17:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.272, 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 LmHXtaiyR698 for ; Wed, 23 Apr 2014 17:44:53 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 94BC81A02BE for ; Wed, 23 Apr 2014 17:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1398300289; x=1429836289; h=from:to:subject:date:message-id:mime-version; bh=i8mlD2941caDdMVV1C1gE40jeI2j+1pzdx4dhVlrgHI=; b=WEAHGZE8TGAXsFnWzv2Ul9/eO5WpLVAFMRwXJDqDpw+6N1HE+Fo9K/b+ vKHXJITfbXt5VTBx06dSDEZxQvXvLLbIU4fb4u1jq86S+n5g5ArqXo995 SmLzkATzyNZffuAsQ4mWAQOMqTkDOBifZ9I9thp3zmbztR3JdMkigzTj7 w=; X-IronPort-AV: E=Sophos;i="4.97,915,1389744000"; d="scan'208,217";a="108753972" X-IPAS-Result: AqMEABteWFPAqArr/2dsb2JhbABagkKBE1e8eoc/gTB0giUBBh1RHQEGAg0EAwECKDkUCQoEARIJiEWOE78oF45HHoQzBJ93jwSCKw Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Apr 2014 00:44:41 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 23 Apr 2014 17:44:39 -0700 From: Sumandra Majee To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPX1ZfU8UhsrhhTUWWEhfLxMVVkQ== Date: Thu, 24 Apr 2014 00:44:39 +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.236] Content-Type: multipart/alternative; boundary="_000_CF7DA6F51E6A5smajeef5com_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XP-tIU3ncea1lkULdTNIds2BImw Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 24 Apr 2014 00:44:55 -0000 --_000_CF7DA6F51E6A5smajeef5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the adoption but I have following observations. 1) Datacenter encompasses a lot of application and varied vertical marke= t. I would like to see this focus on the enterprise and perhaps the cloud D= C use cases. Service providers use data center too, but the policies are of= ten applied per subscriber and per resource (URL), per application. Enterpr= ise datacenter policy may not involve per user policy (I think most will no= t but it does involve a group of users). There are layers of ADC in the enterprise in the form of, L4 distribution =97=97=97=97 ADC 1(with a unicast VIP1) [APP resource] = =97=97=97=97=97 ADC2 (VIP2 : APP resource 2). These can be viewed as same= instance or sometimes NOT. 2) In the mobile DC when flows are threaded thru a series of VAS, the 5 tu= ple remain unchanged. That is not the case in enterprise when there is a se= rver to server communication on behalf of a client. The east west traffic = in cloud DC is quite unruly since the changes are made often and new servic= es are created by DevOps every so often. I think this is a significantly d= ifferent from SP datacenter (where scale matters but number of unique appli= cations are relatively small) and should be covered in detail. I would rather see the focus on enterprise/cloud (call this draft-enterpris= e-=85.) and cover the uniqueness of that piece of land than a generic DC. Regards. Sumandra From: "Jim Guichard (jguichar)" > Date: Friday, April 18, 2014 at 3:31 To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF7DA6F51E6A5smajeef5com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5FD185A833559D448F4620827117BDBE@F5.com> Content-Transfer-Encoding: quoted-printable
I support the adoption but I have following observations.

  1)  Datacenter encompasses a lot of application and varied= vertical market. I would like to see this focus on the enterprise and perh= aps the cloud DC use cases. Service providers use data center too, but the = policies are often applied per subscriber and per resource (URL), per application. Enterprise datacenter policy may = not involve per user policy (I think most will not but it does involve a gr= oup of users).  

There are layers of ADC in the enterprise in the form of,
   L4 distribution  =97=97=97=97 ADC 1(with a unicast V= IP1) [APP resource]  =97=97=97=97=97  ADC2 (VIP2 : APP resource 2= ). These can be viewed as same instance or sometimes NOT. 

2) In the mobile DC when flows are threaded thru a series of VAS, &nbs= p;the 5 tuple remain unchanged. That is not the case in enterprise when the= re is a server to server communication on behalf of a client.  The eas= t west traffic in cloud DC is quite unruly since the changes are made often and new services are created by DevOps &n= bsp;every so often. I think this is a significantly different from SP datac= enter (where scale matters but number of unique applications are relatively= small) and should be covered in detail.

I would rather see the focus on enterprise/cloud (call this draft-ente= rprise-=85.) and cover the uniqueness of that piece of land than a generic = DC.

Regards.

Sumandra

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, April 18, 2014 at 3:3= 1 
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-kumar-sfc-dc-use-cases-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
 --_000_CF7DA6F51E6A5smajeef5com_-- From nobody Wed Apr 23 18:02: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 152531A02BE for ; Wed, 23 Apr 2014 18:02:54 -0700 (PDT) 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 wTv90h2wzePt for ; Wed, 23 Apr 2014 18:02:51 -0700 (PDT) Received: from smtp113.ord1c.emailsrvr.com (smtp113.ord1c.emailsrvr.com [108.166.43.113]) by ietfa.amsl.com (Postfix) with ESMTP id 251CB1A02BB for ; Wed, 23 Apr 2014 18:02:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A3EC31B8710; Wed, 23 Apr 2014 21:02:24 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id D6BA51B85F3; Wed, 23 Apr 2014 21:02:16 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AC396778-6374-43D9-B6CF-51A8EDD74ACB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Barry Greene In-Reply-To: Date: Thu, 24 Apr 2014 08:02:06 +0700 Message-Id: <34A254A7-000E-4A38-B28E-70DC21F06AAD@senki.org> References: To: Sumandra Majee X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4y9lvE2ds_H78Qk6mrfd_aSoGFg Cc: Jim Guichard , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 24 Apr 2014 01:02:54 -0000 --Apple-Mail=_AC396778-6374-43D9-B6CF-51A8EDD74ACB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I echo Sumandra's observation. This needs another section to provide = context, but the model in the use cases section would work with each = context.=20 Additionally, the "use cases" section does not read as "use cases." It = is a very useful tool to use in SFC design in a DC, but not what you = usually see as "use cases." On Apr 24, 2014, at 7:44 AM, Sumandra Majee wrote: > I support the adoption but I have following observations. >=20 > 1) Datacenter encompasses a lot of application and varied vertical = market. I would like to see this focus on the enterprise and perhaps the = cloud DC use cases. Service providers use data center too, but the = policies are often applied per subscriber and per resource (URL), per = application. Enterprise datacenter policy may not involve per user = policy (I think most will not but it does involve a group of users). =20 >=20 > There are layers of ADC in the enterprise in the form of, > L4 distribution =97=97=97=97 ADC 1(with a unicast VIP1) [APP = resource] =97=97=97=97=97 ADC2 (VIP2 : APP resource 2). These can be = viewed as same instance or sometimes NOT.=20 >=20 > 2) In the mobile DC when flows are threaded thru a series of VAS, the = 5 tuple remain unchanged. That is not the case in enterprise when there = is a server to server communication on behalf of a client. The east = west traffic in cloud DC is quite unruly since the changes are made = often and new services are created by DevOps every so often. I think = this is a significantly different from SP datacenter (where scale = matters but number of unique applications are relatively small) and = should be covered in detail. >=20 > I would rather see the focus on enterprise/cloud (call this = draft-enterprise-=85.) and cover the uniqueness of that piece of land = than a generic DC. >=20 > Regards. >=20 > Sumandra >=20 > From: "Jim Guichard (jguichar)" > Date: Friday, April 18, 2014 at 3:31=20 > To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 >=20 > Dear WG: >=20 > This message begins a two week call for WG adoption of the document = http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd = May 2014.=20 >=20 > Please respond to the SFC mailing list with any statements of approval = or disapproval. >=20 > Please note: > =95 This is not WG Last Call. The document is not final, and the = WG is expected to modify the document=92s content until there is WG = consensus that the content is solid. Therefore, please don=92t oppose = adoption just because you want to see changes to its content. > =95 If you have objections to adoption of the document, please = state your reasons why, and explain what it would take to address your = concerns. > =95 If you have issues with the content, by all means raise = those issues and we can begin a dialog about how best to address them.=20= > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_AC396778-6374-43D9-B6CF-51A8EDD74ACB 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 iQEcBAEBCgAGBQJTWGKOAAoJEFVuk3AWv0XztXoIAIiAizfICMX8JjtXv2U7HnTR AwF9dxP4bc3XaHxyrG/6oQ1WmyHGiKyLPAASwuGSri8lTUj6lj6k0K8qWlOnDCLX aEB+t4TWHh1NFrsIyfFKwSOQB2A2P6+/rA+LCNvYrtNQS4XUxqGxb9iTL0fxPnq9 0LNUxh76cyziNiLVHAMW/7dSnFYAvbVUyM77zmch2CY/Vv2bPbAC1WeTkZWrJqqk Co9Kaem1sPNAzFLQJ5R39aLuWvqIH8ZG9uGIqVlmAlZQVuZLEV07ghas8kYxXFFx LUFIZh4vxA8aUJzAnlojOcsZE1XW8jq3KlbLxc2db3hqL7UdAfKJU28FSfvcECQ= =NxYf -----END PGP SIGNATURE----- --Apple-Mail=_AC396778-6374-43D9-B6CF-51A8EDD74ACB-- From nobody Wed Apr 23 21:05: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 B35581A02A3 for ; Wed, 23 Apr 2014 21:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 fTFJw_4o6v0u for ; Wed, 23 Apr 2014 21:04:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0F1A0422 for ; Wed, 23 Apr 2014 21:04:57 -0700 (PDT) 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 BGA24238; Thu, 24 Apr 2014 04:04:50 +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; Thu, 24 Apr 2014 05:04:08 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 05:04:49 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.24]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 12:04:39 +0800 From: Weixinpeng To: "walter.haeffner@vodafone.com" , "sfc@ietf.org" , "jguichar@cisco.com" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsgKLoQ Date: Thu, 24 Apr 2014 04:04:38 +0000 Message-ID: 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.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D7FE501nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lHAjuNe3Ih5TFIY5oAGGF0MWUlY Cc: "Xiongchunshan \(Sam\)" , "Luwei \(Wei\)" , "Zhouhan \(Joe\)" , "Zhulei \(MBB Research\)" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 24 Apr 2014 04:05:02 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D7FE501nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Support the document. But I still have some questions: 1. In section 6.1, it states that "The creation of service chains should be embedded in the business and operation support layers of the company and on an abstract functional level..." so what "the business an= d operation support layers" mean here, it's the OSS/BSS or other entities in 3GPP network? 2. As my understanding, the requirement from operator is that the operator = generates an abstract functional level service chain, and sends it to the controller in SFC framework to form a service function chain instance, = the chain compiler and mediation device in figure 10 are a functional part = of controller, am I right? Thanks, Xinpeng From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, April 19, 2014 6:30 AM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_C5C3BB522B1DDF478AA09545169155B46D7FE501nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Support th= e document. But I still have some questions:

 = ;

1. In section 6.1, it states that “The creation of service chains should

&= nbsp;  be embedded in the business and operation support layers of the=

   company and on an = abstract functional level…” so what “the business and operation support layers” mean here, it̵= 7;s

the OSS/BS= S or other entities in 3GPP network?

2. As my u= nderstanding, the requirement from operator is that the operator generates = an abstract functional level service chain, and sends it to

the contro= ller in SFC framework to form a service function chain instance, the chain = compiler and mediation device in figure 10 are a functional part of controller, am I right?

 = ;

Thanks,

Xinpeng

 = ;

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, April 19, 2014 6:30 AM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

Dear WG:

 <= /o:p>

This message= begins a two week call for WG adoption of the document http://www= .ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

 <= /o:p>

Please respo= nd to the SFC mailing list with any statements of approval or disapproval.<= o:p>

 <= /o:p>

Please note:=

  1. This is not WG Last Call. The document is not f= inal, and the WG is expected to modify the document’s content until t= here is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its co= ntent.
  2. If you have objections to adoption of the docum= ent, please state your reasons why, and explain what it would take to addre= ss your concerns.
  3. If you have issues with the content, by all mea= ns raise those issues and we can begin a dialog about how best to address t= hem. 
--_000_C5C3BB522B1DDF478AA09545169155B46D7FE501nkgeml507mbxchi_-- From nobody Wed Apr 23 22:41: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 A9E631A07A8 for ; Wed, 23 Apr 2014 22:41:38 -0700 (PDT) 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 oaWvcll1a-Ys for ; Wed, 23 Apr 2014 22:41:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9C81A07A6 for ; Wed, 23 Apr 2014 22:41:36 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6BCAC2DC4E7; Thu, 24 Apr 2014 07:41:29 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4FB6527C053; Thu, 24 Apr 2014 07:41:29 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 24 Apr 2014 07:41:29 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Thu, 24 Apr 2014 07:41:26 +0200 Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsgSK2A Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B44EE4@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_94C682931C08B048B7A8645303FDC9F36F58B44EE4PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.32419 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-Z9hZ3mxFVwpeiFD7YColazTHS0 Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 24 Apr 2014 05:41:38 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F58B44EE4PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I don't support the adoption of this draft for the reasons already listed i= n the list. I'm for one single use case document. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : samedi 19 avril 2014 00:30 =C0 : sfc@ietf.org Objet : [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is exp= ected to modify the document's content until there is WG consensus that the= content is solid. Therefore, 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 a= nd we can begin a dialog about how best to address them. --_000_94C682931C08B048B7A8645303FDC9F36F58B44EE4PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I don’t support the adoption of this draft for the reasons alread= y listed in the list. I’m for one single use case document.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.or= g] De la part de Jim Guichard (jguichar)
Envoy=E9 : s= amedi 19 avril 2014 00:30
=C0 : sfc@ietf.org
Objet&nbs= p;: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01<= o:p>

 

=

Dear WG:

 

This message begins a two week call for WG adoption of the doc= ument http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-= 01.txt ending 2nd May 2014. 

=

 

Please respond to the SFC mailing list with any statement= s of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not f= inal, and the WG is expected to modify the document’s content until t= here is WG consensus that the content is solid. Therefore, please don’= ;t oppose adoption just because you want to see changes to its content.
  2. If you have object= ions to adoption of the document, please state your reasons why, and explai= n 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 addres= s them. 
= --_000_94C682931C08B048B7A8645303FDC9F36F58B44EE4PUEXCB1Bnante_-- From nobody Wed Apr 23 22:42: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 5D3A91A07AC for ; Wed, 23 Apr 2014 22:41:49 -0700 (PDT) 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 fLxsPMN84_6Y for ; Wed, 23 Apr 2014 22:41:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE51A07AA for ; Wed, 23 Apr 2014 22:41:47 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7ACC72AC398; Thu, 24 Apr 2014 07:41:40 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 618FC384066; Thu, 24 Apr 2014 07:41:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 24 Apr 2014 07:41:40 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Thu, 24 Apr 2014 07:41:38 +0200 Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsgSQUw Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B44EE5@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_94C682931C08B048B7A8645303FDC9F36F58B44EE5PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.32419 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PExvpAEG086TBrLs88oOc8puHk8 Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 24 Apr 2014 05:41:49 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F58B44EE5PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I don't support the adoption of this draft for the reasons already listed i= n the list. I'm for one single use case document. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : samedi 19 avril 2014 00:32 =C0 : sfc@ietf.org Objet : [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is exp= ected to modify the document's content until there is WG consensus that the= content is solid. Therefore, 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 a= nd we can begin a dialog about how best to address them. --_000_94C682931C08B048B7A8645303FDC9F36F58B44EE5PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I don’t support the adoption of this draft for the reasons alread= y listed in the list. I’m for one single use case document.

 

Cheers,

Med

 

&n= bsp;

De = ;: sfc [mailto:sfc-bounces@ietf.org] De la part de Jim = Guichard (jguichar)
Envoy=E9 : samedi 19 avril 2014 00:32=C0 : sfc@ietf.org
Objet : [sfc] Call for adopt= ion of draft-kumar-sfc-dc-use-cases-01

 

= Dear WG:

&= nbsp;

This message beg= ins a two week call for WG adoption of the document http://www.ietf.org/id= /draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC mai= ling list with any statements of approval or disapproval.=

 

=

Please note:

  1. This is not WG Las= t 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= . Therefore, please don’t oppose adoption just because you want to se= e 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.<= o:p>
  3. If you have issu= es with the content, by all means raise those issues and we can begin a dia= log about how best to address them. 
=
= --_000_94C682931C08B048B7A8645303FDC9F36F58B44EE5PUEXCB1Bnante_-- From nobody Wed Apr 23 22:49: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 5009C1A0062 for ; Wed, 23 Apr 2014 22:49:15 -0700 (PDT) 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 bLnsSDvEGz6Q for ; Wed, 23 Apr 2014 22:49:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEFA1A003B for ; Wed, 23 Apr 2014 22:49:13 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7D34D2AC27B for ; Thu, 24 Apr 2014 07:49:07 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 68EE438406E for ; Thu, 24 Apr 2014 07:49:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 24 Apr 2014 07:49:07 +0200 From: To: "sfc@ietf.org" Date: Thu, 24 Apr 2014 07:49:06 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt Thread-Index: Ac9ZcqTW4c5dD8OYRq2XA6WUy4zAbwGDeLgA Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B44EE6@PUEXCB1B.nanterre.francetelecom.fr> References: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> In-Reply-To: <20140416124740.17502.90360.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.4.24.32419 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2aN4zAPlfj8W1p1jJDS1x7CzBQU Subject: [sfc] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-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, 24 Apr 2014 05:49:15 -0000 Dear all, This draft targets mainly pcp wg but I'm sharing here because it might be o= f interest.=20 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 16 avril 2014 14:48 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP as a Traffic Classifier Control Protocol Author : Mohamed Boucadair Filename : draft-boucadair-pcp-sfc-classifier-control-00.txt Pages : 7 Date : 2014-04-16 Abstract: This document specifies how PCP (Port Control Protocol) can be used as a classifier control protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sfc-classifier-control= / There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00 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 nobody Wed Apr 23 23:12: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 C85951A0062 for ; Wed, 23 Apr 2014 23:11:54 -0700 (PDT) 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 Y0vU8XPRGzH3 for ; Wed, 23 Apr 2014 23:11:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9C1A02CA for ; Wed, 23 Apr 2014 23:11:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id ECEE922C115; Thu, 24 Apr 2014 08:11:38 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id CC39A35C045; Thu, 24 Apr 2014 08:11:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 24 Apr 2014 08:11:38 +0200 From: To: Lucy yong , Ron Parker , "Jim Guichard (jguichar)" , Sharon Date: Thu, 24 Apr 2014 08:11:36 +0200 Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTRUhA6Ab40kaZyfxW4WYVnJsUw7DQgAGCMACAAAPMAIAAAYSA//+NsZCACnkxMA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B44EEB@PUEXCB1B.nanterre.francetelecom.fr> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D453714BA@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453714BA@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: 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.4.24.50019 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uJ4fCpfC1ApufyDj0q8bLfrounE Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 24 Apr 2014 06:11:55 -0000 Dear Lucy, A requirement draft I'm aware of (https://tools.ietf.org/html/draft-boucada= ir-sfc-requirements-04) includes one single item covering this point: REQ#22: The solution MUST allow for the association of a context with the data packets. In particular: A. The solution MUST support the ability to invoke differentiated sets of policies for a Service Function (such sets of policies are called Profiles). A profile denotes a set of policies configured to a local Service Function (e.g., content-filter-child, content-filter- adult). a. Few profiles should be assumed per Service Function to accommodate the need for scalable solutions. b. A finer granularity of profiles may be configured directly to each Service Function; there is indeed no need to overload the design of Service Function Chains with policies of low-level granularity. Additional requirements can be added to capture and record the wg inputs. I= would prefer to see first the document adopted as WG item before going tha= t path. Back to the point mentioned by Sharon, I do think this is worth to be consi= dered but not in the problem statement document. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Lucy yong >Envoy=E9=A0: jeudi 17 avril 2014 16:06 >=C0=A0: Ron Parker; Jim Guichard (jguichar); Sharon >Cc=A0: sfc@ietf.org >Objet=A0: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >I agree that Sharon's use case is very important. > >This metadata feature should be captured in the SFC requirement document. = I >am surprised in seeing no metadata word mentioned in the requirement doc. >yet. > >Lucy > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Thursday, April 17, 2014 8:55 AM >To: Jim Guichard (jguichar); Sharon; Lucy yong >Cc: sfc@ietf.org >Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >I think Sharon's use case is very important. But, so long as the >interpretation of metadata is not prescriptive in the problem statement, >wouldn't this be more appropriate for the use cases document? > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >(jguichar) >Sent: Thursday, April 17, 2014 9:49 AM >To: Sharon; Lucy yong >Cc: sfc@ietf.org >Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >Hi Sharon, > >I would like to just clarify that I understand your second point. I believ= e >you are saying that you would like the data plane metadata to carry >pointers (rather than the full metadata structure) that may be used for ke= y >access into a more detailed data structure within the SF itself correct? > >On 4/17/14, 9:35 AM, "Sharon" wrote: > >>I agree. Text shapes up nicely. >>Also re-entrant re-classify recursion spelled out for dynamic forks. >>We are starting to see functions designed with programability in mind >>that need it. >> >>Would like to see the option of metadata as mappable (eid) key at least >>mentioned. >>While it does require some state savings per flow (sfc is very much a >>flow thing ..), It helps address the different fields that come up, the >>per packet overhead, out of band complexity-consistency.. reduces the >>problem to mapping, something we have to solve anyway in many of the >>sfc use cases. >> >>--szb >> >>> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>> >>> I like the new text about dataplane metadata in section 3.4. >>> >>> Cheers, >>> Lucy >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>internet-drafts@ietf.org >>> Sent: Wednesday, April 16, 2014 2:18 PM >>> To: i-d-announce@ietf.org >>> Cc: sfc@ietf.org >>> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Service Function Chaining Working >>>Group of the IETF. >>> >>> Title : Service Function Chaining Problem Statement >>> Authors : Paul Quinn >>> Thomas Nadeau >>> Filename : draft-ietf-sfc-problem-statement-04.txt >>> Pages : 18 >>> Date : 2014-04-16 >>> >>> 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 instances 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-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> 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 nobody Wed Apr 23 23:27: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 E96631A07A2 for ; Wed, 23 Apr 2014 23:27:29 -0700 (PDT) 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 DaqapSBOl0Hh for ; Wed, 23 Apr 2014 23:27:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9E31A079C for ; Wed, 23 Apr 2014 23:27:28 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 4BF351901E9 for ; Thu, 24 Apr 2014 08:27:22 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2A147158063 for ; Thu, 24 Apr 2014 08:27:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 24 Apr 2014 08:27:21 +0200 From: To: "sfc@ietf.org" Date: Thu, 24 Apr 2014 08:27:20 +0200 Thread-Topic: IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6Q== Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@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_94C682931C08B048B7A8645303FDC9F36F58B44EEFPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.50019 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/txwOAP8tilXojWPxwas3UD5NKVU Subject: [sfc] IPR related to draft-ietf-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, 24 Apr 2014 06:27:30 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F58B44EEFPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I'm surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3). I'm re-iterating my comment to remove section 3 from the PS draft as it see= ms this is the only part that is close to the solution part than the proble= m discussion. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36F58B44EEFPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

<= p class=3DMsoNormal> 

When checking the tracker, I found the= re is an IPR disclosure for the problem statement document:

https://datatracke= r.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft-ietf-sfc-pro= blem-statement

 

I’m surprised to see such disclosure for a document that is sup= posed to describe only problems (except section 3).

I’m re-iterating my comment to re= move section 3 from the PS draft as it seems this is the only part that is = close to the solution part than the problem discussion. <= /p>

 

Cheers,

= Med

= --_000_94C682931C08B048B7A8645303FDC9F36F58B44EEFPUEXCB1Bnante_-- From nobody Wed Apr 23 23:52: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 72B5D1A07AB for ; Wed, 23 Apr 2014 23:52:54 -0700 (PDT) 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 3mhCnPVyxySr for ; Wed, 23 Apr 2014 23:52:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1349A1A008D for ; Wed, 23 Apr 2014 23:52:51 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3D3D3324224; Thu, 24 Apr 2014 08:52:45 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 20CA3238048; Thu, 24 Apr 2014 08:52:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 24 Apr 2014 08:52:44 +0200 From: To: "sarikaya@ieee.org" , "sfc@ietf.org" Date: Thu, 24 Apr 2014 08:52:43 +0200 Thread-Topic: [sfc] Fwd: New Version Notification for draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt Thread-Index: Ac9dnEouo2rJbO8YSG+3swiOq0DxWAB62Agw Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B44EFB@PUEXCB1B.nanterre.francetelecom.fr> References: <20140421195656.18585.39798.idtracker@ietfa.amsl.com> 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_94C682931C08B048B7A8645303FDC9F36F58B44EFBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.50019 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ruDwPf2R_v-DSr1xOjm-DyEDWXU Subject: Re: [sfc] Fwd: New Version Notification for draft-xue-sfc-address-sharing-in-sfc-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, 24 Apr 2014 06:52:54 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F58B44EFBPUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVoY2V0LA0KDQpUaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhpcyBkb2N1bWVudC4gQmVsb3cg c29tZSBjb21tZW50czoNCg0KDQrCtyAgICAgICAgIFRoZSBkb2N1bWVudCBkb2VzIG5vdCBleHBs aWNpdCBpZiB0aGlzIGlzIHNwZWNpZmljIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGNhc2Ugb3Ig aWYgaXQgaXMgYSBnZW5lcmljIGNvbmNlcm4uIE9uZSBjYW4gYXJndWUgdGhlIHByb2JsZW0gYXBw bGllcyBpbmRlcGVuZGVudGx5IG9mIHNlcnZpY2UgY2hhaW5pbmcuIEl0IHdvdWxkIGJlIHVzZWZ1 bCB0byBpbmNsdWRlIHN1Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgdGV4dCB3aXRoIGEgZm9jdXMgb24g c2VydmljZSBjaGFpbmluZy4NCg0KwrcgICAgICAgICBNYW5kYXRpbmcgYWxsIFNGcyBhcmUgYWJs ZSB0byBkZWNyeXB0IGVuY3J5cHRlZCB0cmFmZmljIGlzIG5vdCB2aWFibGUgSU1ITy4NCg0Kwrcg ICAgICAgICBJZiB0aGUgcHJvYmxlbSBpcyBvbmx5IHNwZWNpZmljIHRvIEhUVFBTLCB3aHkgbm90 IHVzZSB0aGUgVENQIG9wdGlvbiBkZWZpbmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdpbGxpYW1zLWV4cC10Y3AtaG9zdC1pZC1vcHQtMDI/DQoNCkhvcGUgdGhhdCBoZWxw cy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUgQmVoY2V0IFNhcmlrYXlhDQpFbnZvecOpIDogbHVuZGkgMjEgYXZy aWwgMjAxNCAyMjowMA0Kw4AgOiBzZmNAaWV0Zi5vcmcNCk9iamV0IDogW3NmY10gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1ZS1zZmMtYWRkcmVzcy1zaGFyaW5nLWlu LXNmYy11c2UtY2FzZXMtMDAudHh0DQoNCkhpIGFsbCwNCldlIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0 LiBJdCBhZGRyZXNzZXMgYW4gaXNzdWUgdGhhdCBpcyBub3QgY292ZXJlZCBpbiB0aGUgdXNlIGNh c2UgYW5kIHJlcXVpcmVtZW50cyBkcmFmdHMuDQpXZSBzb2xpY2l0IHRoYXQgaXQgc2hvdWxkIGJl Lg0KUmVnYXJkcywNCkJlaGNldA0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXh1 ZS1zZmMtYWRkcmVzcy1zaGFyaW5nLWluLXNmYy11c2UtY2FzZXMtMDAudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJlaGNldCBTYXJpa2F5YSBhbmQgcG9zdGVkIHRvIHRo ZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQteHVlLXNmYy1hZGRy ZXNzLXNoYXJpbmctaW4tc2ZjLXVzZS1jYXNlcw0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTog ICAgICAgICAgSG9zdCBJZGVudGlmaWNhdGlvbiBQcm9ibGVtIGluIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW5pbmcgVXNlIENhc2VzDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wNC0yMQ0KR3JvdXA6ICAg ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDcNClVSTDogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dWUtc2Zj LWFkZHJlc3Mtc2hhcmluZy1pbi1zZmMtdXNlLWNhc2VzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1ZS1zZmMtYWRkcmVzcy1z aGFyaW5nLWluLXNmYy11c2UtY2FzZXMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQteHVlLXNmYy1hZGRyZXNzLXNoYXJpbmctaW4tc2ZjLXVzZS1jYXNl cy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0 byBwcmVzZW50IGhvc3QgaWRlbnRpZmljYXRpb24NCiAgIHByb2JsZW0gZHVlIHRvIHRoZSBhZGRy ZXNzIGFuZCBwcmVmaXggc2hhcmluZyBpbiBzZXJ2aWNlIGZ1bmN0aW9uDQogICBjaGFpbmluZy4g IFNvIGZhciB3ZSBoYXZlIGlkZW50aWZpZWQgdGhpcyBwcm9ibGVtIGluIHRoZSB0d28gdXNlDQog ICBjYXNlcyBvZiB0aGUgcGFyZW50YWwgY29udHJvbCBzZXJ2aWNlIGFuZCBvZmZsb2FkaW5nIHNl cnZpY2UgYnV0IGl0DQogICBpcyBsaWtlbHkgdGhhdCBtb3JlIHVzZSBjYXNlcyBjYW4gYmUgaWRl bnRpZmllZC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8v dG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= --_000_94C682931C08B048B7A8645303FDC9F36F58B44EFBPUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTUxNjQ1OTMzOTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTk0ODA0MDA3NCAt MjMxMTQ4MDM2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt c3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3 RCc+SGkgQmVoY2V0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6IzFGNDk3RCc+VGhhbmsgeW91IGZvciBzaGFyaW5nIHRoaXMgZG9jdW1lbnQuIEJlbG93 IHNvbWUgY29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Okln bm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPlRoZSBkb2N1bWVudCBkb2VzIG5vdCBleHBs aWNpdCBpZiB0aGlzIGlzIHNwZWNpZmljIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGNhc2Ugb3Ig aWYgaXQgaXMgYSBnZW5lcmljIGNvbmNlcm4uIE9uZSBjYW4gYXJndWUgdGhlIHByb2JsZW0gYXBw bGllcyBpbmRlcGVuZGVudGx5IG9mIHNlcnZpY2UgY2hhaW5pbmcuIEl0IHdvdWxkIGJlIHVzZWZ1 bCB0byBpbmNsdWRlIHN1Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgdGV4dCB3aXRoIGEgZm9jdXMgb24g c2VydmljZSBjaGFpbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v cmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5NYW5kYXRpbmcgYWxsIFNGcyBhcmUgYWJsZSB0 byBkZWNyeXB0IGVuY3J5cHRlZCB0cmFmZmljIGlzIG5vdCB2aWFibGUgSU1ITy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5 N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4w cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdE Jz5JZiB0aGUgcHJvYmxlbSBpcyBvbmx5IHNwZWNpZmljIHRvIEhUVFBTLCB3aHkgbm90IHVzZSB0 aGUgVENQIG9wdGlvbiBkZWZpbmVkIGluIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXdpbGxpYW1zLWV4cC10Y3AtaG9zdC1pZC1vcHQtMDIiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdpbGxpYW1zLWV4cC10Y3AtaG9zdC1pZC1vcHQtMDI8L2E+PyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0Qn PkhvcGUgdGhhdCBoZWxwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOiMxRjQ5N0QnPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+TWVkPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIDxiPkRlIGxhIHBhcnQgZGU8L2I+IEJlaGNldCBT YXJpa2F5YTxicj48Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMjEgYXZyaWwgMjAxNCAyMjow MDxicj48Yj7DgCZuYnNwOzo8L2I+IHNmY0BpZXRmLm9yZzxicj48Yj5PYmpldCZuYnNwOzwvYj48 L3NwYW4+PGI+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RlIgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gW3Nm Y10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1ZS1zZmMtYWRkcmVz cy1zaGFyaW5nLWluLXNmYy11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2Pjxk aXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5X ZSBzdWJtaXR0ZWQgdGhpcyBkcmFmdC4gSXQgYWRkcmVzc2VzIGFuIGlzc3VlIHRoYXQgaXMgbm90 IGNvdmVyZWQgaW4gdGhlIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudHMgZHJhZnRzLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPldlIHNvbGljaXQgdGhhdCBpdCBzaG91bGQgYmUuPG86cD48L286cD48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QmVoY2V0PG86cD48L286cD48L3A+ PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+QSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXh1ZS1zZmMtYWRkcmVzcy1zaGFyaW5nLWluLXNmYy11c2UtY2Fz ZXMtMDAudHh0PGJyPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmVoY2V0IFNh cmlrYXlhIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPklFVEYgcmVwb3NpdG9yeS48YnI+PGJyPk5hbWU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQteHVlLXNmYy1hZGRyZXNz LXNoYXJpbmctaW4tc2ZjLXVzZS1jYXNlczxicj5SZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJz cDsgMDA8YnI+VGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIb3N0IElk ZW50aWZpY2F0aW9uIFByb2JsZW0gaW4gU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBVc2UgQ2Fz ZXM8YnI+RG9jdW1lbnQgZGF0ZTogJm5ic3A7MjAxNC0wNC0yMTxicj5Hcm91cDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lvbjxicj5QYWdlczog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzc8YnI+VVJMOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1ZS1zZmMtYWRkcmVzcy1zaGFyaW5nLWluLXNmYy11c2Ut Y2FzZXMtMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQteHVlLXNmYy1hZGRyZXNzLXNoYXJpbmctaW4tc2ZjLXVzZS1jYXNlcy0w MC50eHQ8L2E+PGJyPlN0YXR1czogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1ZS1zZmMtYWRkcmVzcy1z aGFyaW5nLWluLXNmYy11c2UtY2FzZXMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHVlLXNmYy1hZGRyZXNzLXNoYXJpbmctaW4tc2ZjLXVz ZS1jYXNlcy88L2E+PGJyPkh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dWUtc2ZjLWFkZHJlc3Mtc2hhcmluZy1p bi1zZmMtdXNlLWNhc2VzLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQteHVlLXNmYy1hZGRyZXNzLXNoYXJpbmctaW4tc2ZjLXVzZS1jYXNlcy0wMDwv YT48YnI+PGJyPjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7ICZuYnNwO1RoZSBwdXJwb3NlIG9mIHRo aXMgZG9jdW1lbnQgaXMgdG8gcHJlc2VudCBob3N0IGlkZW50aWZpY2F0aW9uPGJyPiZuYnNwOyAm bmJzcDtwcm9ibGVtIGR1ZSB0byB0aGUgYWRkcmVzcyBhbmQgcHJlZml4IHNoYXJpbmcgaW4gc2Vy dmljZSBmdW5jdGlvbjxicj4mbmJzcDsgJm5ic3A7Y2hhaW5pbmcuICZuYnNwO1NvIGZhciB3ZSBo YXZlIGlkZW50aWZpZWQgdGhpcyBwcm9ibGVtIGluIHRoZSB0d28gdXNlPGJyPiZuYnNwOyAmbmJz cDtjYXNlcyBvZiB0aGUgcGFyZW50YWwgY29udHJvbCBzZXJ2aWNlIGFuZCBvZmZsb2FkaW5nIHNl cnZpY2UgYnV0IGl0PGJyPiZuYnNwOyAmbmJzcDtpcyBsaWtlbHkgdGhhdCBtb3JlIHVzZSBjYXNl cyBjYW4gYmUgaWRlbnRpZmllZC48YnI+PGJyPjxicj48YnI+PGJyPlBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b248YnI+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5p ZXRmLm9yZzwvYT4uPGJyPjxicj5UaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_94C682931C08B048B7A8645303FDC9F36F58B44EFBPUEXCB1Bnante_-- From nobody Thu Apr 24 01:07: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 96C701A0109 for ; Thu, 24 Apr 2014 01:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.478 X-Spam-Level: * X-Spam-Status: No, score=1.478 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.272, 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 F8kfq0W8RtFR for ; Thu, 24 Apr 2014 01:07:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 375831A00DA for ; Thu, 24 Apr 2014 01:07:16 -0700 (PDT) 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 BGA43078; Thu, 24 Apr 2014 08:07:09 +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; Thu, 24 Apr 2014 09:06:25 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 09:07:07 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 16:07:02 +0800 From: Xuxiaohu To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QADbnUA Date: Thu, 24 Apr 2014 08:07:01 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826D704@NKGEML512-MBS.china.huawei.com> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826D704NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6AkpSscwhBgPrntyDvEDqZT4d9g Subject: [sfc] =?gb2312?b?tPC4tDogSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1zZmMt?= =?gb2312?b?cHJvYmxlbS1zdGF0ZW1lbnQ=?= 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, 24 Apr 2014 08:07:21 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826D704NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzEuDQoNCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjI0yNUgMTQ6MjcN CsrVvP7Iyzogc2ZjQGlldGYub3JnDQrW98ziOiBbc2ZjXSBJUFIgcmVsYXRlZCB0byBkcmFmdC1p ZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudA0KDQpEZWFyIGFsbCwNCg0KV2hlbiBjaGVja2luZyB0 aGUgdHJhY2tlciwgSSBmb3VuZCB0aGVyZSBpcyBhbiBJUFIgZGlzY2xvc3VyZSBmb3IgdGhlIHBy b2JsZW0gc3RhdGVtZW50IGRvY3VtZW50Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvc2VhcmNoLz9vcHRpb249ZG9jdW1lbnRfc2VhcmNoJmlkPWRyYWZ0LWlldGYtc2ZjLXByb2Js ZW0tc3RhdGVtZW50DQoNCkmhr20gc3VycHJpc2VkIHRvIHNlZSBzdWNoIGRpc2Nsb3N1cmUgZm9y IGEgZG9jdW1lbnQgdGhhdCBpcyBzdXBwb3NlZCB0byBkZXNjcmliZSBvbmx5IHByb2JsZW1zIChl eGNlcHQgc2VjdGlvbiAzKS4NCg0KSaGvbSByZS1pdGVyYXRpbmcgbXkgY29tbWVudCB0byByZW1v dmUgc2VjdGlvbiAzIGZyb20gdGhlIFBTIGRyYWZ0IGFzIGl0IHNlZW1zIHRoaXMgaXMgdGhlIG9u bHkgcGFydCB0aGF0IGlzIGNsb3NlIHRvIHRoZSBzb2x1dGlvbiBwYXJ0IHRoYW4gdGhlIHByb2Js ZW0gZGlzY3Vzc2lvbi4NCg0KQ2hlZXJzLA0KTWVkDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826D704NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1.

 

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounc= es@ietf.org] =B4=FA=B1=ED = mohamed.boucadair@orange.com
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA4=D4=C2<= span lang=3D"EN-US">24=C8=D5 14:27
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,

 

When checking the tracker, I found there is= an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id= =3Ddraft-ietf-sfc-problem-statement

 

I=A1=AFm surprised to see such disclosure f= or a document that is supposed to describe only problems (except section 3)= .

 

I=A1=AFm re-iterating my comment to remove = section 3 from the PS draft as it seems this is the only part that is close= to the solution part than the problem discussion.

 

Cheers,

Med

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826D704NKGEML512MBSchi_-- From nobody Thu Apr 24 03:37: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 418441A010F for ; Thu, 24 Apr 2014 03:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 tNUUr9d2F3SB for ; Thu, 24 Apr 2014 03:37:02 -0700 (PDT) Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3B97E1A0045 for ; Thu, 24 Apr 2014 03:37:02 -0700 (PDT) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailout03.vodafone.com (Postfix) with ESMTP id E931A14056E for ; Thu, 24 Apr 2014 12:36:52 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id D4097140B7F; Thu, 24 Apr 2014 12:36:52 +0200 (CEST) Received: from VOEXM20W.internal.vodafone.com ([169.254.4.32]) by VOEXC06W.internal.vodafone.com ([145.230.101.26]) with mapi id 14.03.0146.002; Thu, 24 Apr 2014 12:36:51 +0200 From: "Haeffner, Walter, Vodafone DE" To: Weixinpeng , "sfc@ietf.org" , "jguichar@cisco.com" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsgKLoQgABcDJA= Date: Thu, 24 Apr 2014 10:36:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE104718537A17507VOEXM20Winterna_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6mNH4sE_Vhveyq_GsiotV6pcbEM Cc: "Xiongchunshan \(Sam\)" , "Luwei \(Wei\)" , "Zhouhan \(Joe\)" , "Zhulei \(MBB Research\)" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 24 Apr 2014 10:37:08 -0000 --_000_C8C844F84E550E43865561FAE104718537A17507VOEXM20Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xipeng, Thanks for supporting our draft. We are currently working on the next editi= on which takes care of all the WG inputs. Wrt section 6.1we had the complete product creation cycle in mind: 1.) Marketing defines a product. 2.) Product (assume a mobile access product) is typically specified by p= arameters like QoS for traffic classes, BW limits, volume limits, charging,= etc. 3.) Marketing asks Product Engineering to specify input to Network/Servi= ce Engineering 4.) Network/Service Engineering maps this into network configs. 5.) Operations finally implements and maintain this config. So you are right. The "dream environment" for an operator would be a stack = with increased abstraction towards the business-oriented layers. Idea is to= think about an abstract SFC graph with branching rules specified on the "p= roduct requirements level" (metadata) and created by Product Engineering in= some fancy tool box. This may be automatically translated into underlay/tu= nnel configs. This fits pretty much with the WG idea of a new abstracted forwarding mecha= nism based on "Base Header" content already proposed in some early drafts. Branching rules are driven by static or time/state dependent metadata conte= xt. You could make the set of metadata bigger and bigger, but the question = is, what is the minimal set and how we may transfer and manage these metada= ta to come to a feasible and useful SFC environment the operators may (step= wise) introduce. We have to think about it. But, SFC cannot and should not = try to solve all the problems on earth. Abstraction is also not a new idea. Have for example a closer look to Brent= Salisbury's recent open source work on Openstack, OVSDB within Opendayligh= t. This may reflect what could be done within a complete SFC framework. For sure and explicitly stated, not all of this is subject of the SFC WG. B= ut an operator is not only asking for a protocol. He asks for a complete so= lution. What is your opinion? Kind regards, Walter Von: Weixinpeng [mailto:weixinpeng@huawei.com] Gesendet: Donnerstag, 24. April 2014 06:05 An: Haeffner, Walter, Vodafone DE; sfc@ietf.org; jguichar@cisco.com Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Research) Betreff: RE: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Hi, Support the document. But I still have some questions: 1. In section 6.1, it states that "The creation of service chains should be embedded in the business and operation support layers of the company and on an abstract functional level..." so what "the business an= d operation support layers" mean here, it's the OSS/BSS or other entities in 3GPP network? 2. As my understanding, the requirement from operator is that the operator = generates an abstract functional level service chain, and sends it to the controller in SFC framework to form a service function chain instance, = the chain compiler and mediation device in figure 10 are a functional part = of controller, am I right? Thanks, Xinpeng From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, April 19, 2014 6:30 AM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_C8C844F84E550E43865561FAE104718537A17507VOEXM20Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xipeng,

 <= /p>

Thanks for supporting our= draft. We are currently working on the next edition which takes care of al= l the WG inputs.

 <= /p>

Wrt section 6.1we had the= complete product creation cycle in mind:

 <= /p>

1.)&nb= sp;   Marketing defines= a product.

2.)&nb= sp;   Product (assume a= mobile access product) is typically specified by parameters like QoS for t= raffic classes, BW limits, volume limits, charging, etc.<= /p>

3.)&nb= sp;   Marketing asks Pr= oduct Engineering to specify input to Network/Service Engineering

4.)&nb= sp;   Network/Service E= ngineering maps this into network configs.

5.)&nb= sp;   Operations finall= y implements and maintain this config.

 <= /p>

So you are right. The = 220;dream environment” for an operator would be a stack with increase= d abstraction towards the business-oriented layers. Idea is to think about an abstract SFC graph with branching rules specified on the “p= roduct requirements level” (metadata) and created by Product Engineer= ing in some fancy tool box. This may be automatically translated into under= lay/tunnel configs.

This fits pretty much wit= h the WG idea of a new abstracted forwarding mechanism based on “Base= Header” content already proposed in some early drafts.

 <= /p>

Branching rules are drive= n by static or time/state dependent metadata context. You could make the se= t of metadata bigger and bigger, but the question is, what is the minimal set and how we may transfer and manage these metadata to co= me to a feasible and useful SFC environment the operators may (stepwise) in= troduce. We have to think about it. But, SFC cannot and should not try to s= olve all the problems on earth.

 <= /p>

Abstraction is also not a= new idea. Have for example a closer look to Brent Salisbury’s recent= open source work on Openstack, OVSDB within Opendaylight. This may reflect what could be done within a complete SFC framework.=

 <= /p>

For sure and explicitly s= tated, not all of this is subject of the SFC WG. But an operator is not onl= y asking for a protocol. He asks for a complete solution.=

 <= /p>

What is your opinion?

 <= /p>

Kind regards,

 <= /p>

Walter<= /p>

 <= /p>

 <= /p>

Von: Weixinpeng [mailto:weixinpeng@huawei.com]
Gesendet: Donnerstag, 24. April 2014 06:05
An: Haeffner, Walter, Vodafone DE; sfc@ietf.org; jguichar@cisco.com
Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Res= earch)
Betreff: RE: Call for adoption of draft-haeffner-sfc-use-case-mobili= ty-01

 

1. In section 6.1, it states that “The creation of service chains should

   be embedded in the business and operation support l= ayers of the

   compan= y and on an abstract functional level…” so what “the business and operation support layers” mean here,= it’s

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, April 19, 2014 6:30 AM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

&nbs= p;

= Dear WG:

=  

= This message begins a two week call for WG adoption of the document http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt&nb= sp;ending 2nd May 2014. 

=  

= Please respond to the SFC mailing list with any statements of approval or d= isapproval.

=  

= Please note:

  1. This is not WG Last Call. The docum= ent is not final, and the WG is expected to modify the document’s con= tent until there is WG consensus that the content is solid. Therefore, 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 t= ake 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 them. 
--_000_C8C844F84E550E43865561FAE104718537A17507VOEXM20Winterna_-- From nobody Thu Apr 24 08:36: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 6F5DA1A028B for ; Thu, 24 Apr 2014 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 BOC2tffbZE1Q for ; Thu, 24 Apr 2014 08:36:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4983C1A02C1 for ; Thu, 24 Apr 2014 08:36:40 -0700 (PDT) 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 BDL54007; Thu, 24 Apr 2014 15:36:31 +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, 24 Apr 2014 16:35:47 +0100 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, 24 Apr 2014 16:36:30 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 08:36:17 -0700 From: Lucy yong To: "mohamed.boucadair@orange.com" , Ron Parker , "Jim Guichard (jguichar)" , Sharon Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTRUhA6Ab40kaZyfxW4WYVnJsUw7DQgAGCMACAAAPMAIAAAYSA//+NsZCACnkxMIAAk4VQ Date: Thu, 24 Apr 2014 15:36:17 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45373045@dfweml701-chm.china.huawei.com> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D453714BA@dfweml701-chm.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F58B44EEB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B44EEB@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.139.244] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bMaLZpPYmBskkxRZGSuol7XJrdM Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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, 24 Apr 2014 15:36:45 -0000 Hi Mohamed, Thank you for the explanation. If the metadata means the association of a c= ontext with the data packets, it is better to explicitly mention that "meta= data" is often term used to such context in the requirement draft as well. = This will make the requirement document better aligns with other PS and oth= er documents. In standard, we often spend a lot of time to make censuses on= one term and/or one description.=20 In PS doc, it defines and explains the data plane metadata, which is one wa= y to convey the association of a context with the data packets, there are o= ther ways to convey such association. =20 Current description in REQ#22 is not clear to me. Profiles/policies are des= cribed as some configuration at local Service Function. It is hard to draw = any relationship to the association of a context with the data packets. Sin= ce the association of a context with data packets or metadata is one of mai= n characteristics that SFC will supports, it is very important for req. doc= to depict the requirements on the metadata.=20 Sharon's case expresses a requirement on data plane metadata. They are othe= rs, e.g. the solution MUST provide the association between the metadata and= its associated data packets in real time. I agree that we should not state= such requirement in PS doc. SFC needs a requirement doc. for sure. IMO: setting a pre-condition for con= tinually working on a doc. is not proper. It is chair's responsibility to d= etermine when to adopt; editor's responsibility to capture the right stuff = in a doc.. Thanks, Lucy =20 -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, April 24, 2014 1:12 AM To: Lucy yong; Ron Parker; Jim Guichard (jguichar); Sharon Cc: sfc@ietf.org Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Dear Lucy, A requirement draft I'm aware of (https://tools.ietf.org/html/draft-boucada= ir-sfc-requirements-04) includes one single item covering this point: REQ#22: The solution MUST allow for the association of a context with the data packets. In particular: A. The solution MUST support the ability to invoke differentiated sets of policies for a Service Function (such sets of policies are called Profiles). A profile denotes a set of policies configured to a local Service Function (e.g., content-filter-child, content-filter- adult). a. Few profiles should be assumed per Service Function to accommodate the need for scalable solutions. b. A finer granularity of profiles may be configured directly to each Service Function; there is indeed no need to overload the design of Service Function Chains with policies of low-level granularity. Additional requirements can be added to capture and record the wg inputs. I= would prefer to see first the document adopted as WG item before going tha= t path. Back to the point mentioned by Sharon, I do think this is worth to be consi= dered but not in the problem statement document. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Lucy yong Envoy=E9= =A0:=20 >jeudi 17 avril 2014 16:06 =C0=A0: Ron Parker; Jim Guichard (jguichar);=20 >Sharon Cc=A0: sfc@ietf.org Objet=A0: Re: [sfc] I-D Action:=20 >draft-ietf-sfc-problem-statement-04.txt > >I agree that Sharon's use case is very important. > >This metadata feature should be captured in the SFC requirement=20 >document. I am surprised in seeing no metadata word mentioned in the requi= rement doc. >yet. > >Lucy > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Thursday, April 17, 2014 8:55 AM >To: Jim Guichard (jguichar); Sharon; Lucy yong >Cc: sfc@ietf.org >Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >I think Sharon's use case is very important. But, so long as the >interpretation of metadata is not prescriptive in the problem=20 >statement, wouldn't this be more appropriate for the use cases document? > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >(jguichar) >Sent: Thursday, April 17, 2014 9:49 AM >To: Sharon; Lucy yong >Cc: sfc@ietf.org >Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >Hi Sharon, > >I would like to just clarify that I understand your second point. I=20 >believe you are saying that you would like the data plane metadata to=20 >carry pointers (rather than the full metadata structure) that may be=20 >used for key access into a more detailed data structure within the SF itse= lf correct? > >On 4/17/14, 9:35 AM, "Sharon" wrote: > >>I agree. Text shapes up nicely. >>Also re-entrant re-classify recursion spelled out for dynamic forks. >>We are starting to see functions designed with programability in mind=20 >>that need it. >> >>Would like to see the option of metadata as mappable (eid) key at=20 >>least mentioned. >>While it does require some state savings per flow (sfc is very much a=20 >>flow thing ..), It helps address the different fields that come up,=20 >>the per packet overhead, out of band complexity-consistency.. reduces=20 >>the problem to mapping, something we have to solve anyway in many of=20 >>the sfc use cases. >> >>--szb >> >>> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>> >>> I like the new text about dataplane metadata in section 3.4. >>> >>> Cheers, >>> Lucy >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>internet-drafts@ietf.org >>> Sent: Wednesday, April 16, 2014 2:18 PM >>> To: i-d-announce@ietf.org >>> Cc: sfc@ietf.org >>> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Service Function Chaining Working=20 >>>Group of the IETF. >>> >>> Title : Service Function Chaining Problem Statement >>> Authors : Paul Quinn >>> Thomas Nadeau >>> Filename : draft-ietf-sfc-problem-statement-04.txt >>> Pages : 18 >>> Date : 2014-04-16 >>> >>> 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 instances 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-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 nobody Thu Apr 24 09:15: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 DE09C1A03B8 for ; Thu, 24 Apr 2014 09:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.172 X-Spam-Level: X-Spam-Status: No, score=-7.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 aGt5qEq3gK_c for ; Thu, 24 Apr 2014 09:15:34 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 953BD1A037A for ; Thu, 24 Apr 2014 09:15:28 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 24 Apr 2014 09:15:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,919,1389772800"; d="scan'208,217";a="423308802" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by azsmga001.ch.intel.com with ESMTP; 24 Apr 2014 09:14:57 -0700 Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 24 Apr 2014 09:14:56 -0700 Received: from orsmsx115.amr.corp.intel.com ([169.254.10.2]) by ORSMSX113.amr.corp.intel.com ([169.254.7.62]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 09:14:56 -0700 From: "Jani, Nrupal" To: "sfc@ietf.org" Thread-Topic: thought for the possible new requirement Thread-Index: Ac9f2FK/kM9cxMQFTOi94coBmqw9VA== Date: Thu, 24 Apr 2014 16:14:55 +0000 Message-ID: <096DE3A060628644893976A610FDE6F26C29EFCF@ORSMSX115.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_096DE3A060628644893976A610FDE6F26C29EFCFORSMSX115amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2SiiTibA3WYF8yVmKo5VOJUg_dA Subject: [sfc] thought for the possible new requirement 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, 24 Apr 2014 16:15:36 -0000 --_000_096DE3A060628644893976A610FDE6F26C29EFCFORSMSX115amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there, First of all, I want to thank this WG for putting out great RFCs capturing = various requirements and usecases. I see possibility of one additional requirement, which is either not captur= ed or is there but not explicit, may be just the interpretation problem!! As we know SFC domain could contain multi-vendor SFs hosted in various form= factors, e.g. Virtual Machine, Linux Container, Bare-Metal or Physical App= liance. Additionally traffic passes through the combination of SW & HW Swi= tches, where there could be a packet loss due to various reasons. While RFCs are calling out OAM, diagnostic and elasticity related requireme= nts and SLA related usacases, I see a need to provide real-time effective B= W for given SFC. It can be useful for runtime provisioning of SFC instance= s (i.e. elasticity) of a given SFC, or to migrate SF instances to an approp= riate SF node!! For the initial thought, SF Node could be a better entity to provide real-t= ime information of each SFC chains, given that it is the anchor point in SF= C related traffic. Or could be some other ways!! Furthermore not related to requirement, but like TPCC perf. matrix from var= ious server platform vendors, having upfront perf. matrix from appliance ve= ndor for a given form factor (i.e. Virtual Machine, Linux Container, Bare-M= etal or Physical Appliance) could help admin initial provisioning of a give= n SFC. Thanks, Nrupal. --_000_096DE3A060628644893976A610FDE6F26C29EFCFORSMSX115amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there,

 

First of all, I want to thank this WG for putting ou= t great RFCs capturing various requirements and usecases. 

 

I see possibility of one additional requirement, whi= ch is either not captured or is there but not explicit, may be just the int= erpretation problem!!

 

As we know SFC domain could contain multi-vendor SFs= hosted in various form factors, e.g. Virtual Machine, Linux Container, Bar= e-Metal or Physical Appliance.  Additionally traffic passes through th= e combination of SW & HW Switches, where there could be a packet loss due to various reasons.

 

While RFCs are calling out OAM, diagnostic and elast= icity related requirements and SLA related usacases, I see a need to provid= e real-time effective BW for given SFC.  It can be useful for runtime = provisioning of SFC instances (i.e. elasticity) of a given SFC, or to migrate SF instances to an appropriate SF node!!

 

For the initial thought, SF Node could be a better e= ntity to provide real-time information of each SFC chains, given that it is= the anchor point in SFC related traffic.   Or could be some othe= r ways!!

 

Furthermore not related to requirement, but like TPC= C perf. matrix from various server platform vendors, having upfront perf. m= atrix from appliance vendor for a given form factor (i.e. Virtual Machine, = Linux Container, Bare-Metal or Physical Appliance) could help admin initial provisioning of a given SFC.

 

Thanks,

 

Nrupal.

 

 

 

--_000_096DE3A060628644893976A610FDE6F26C29EFCFORSMSX115amrcor_-- From nobody Thu Apr 24 09:26: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 2AC441A02AD for ; Thu, 24 Apr 2014 09:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 bD-SuPdxjgph for ; Thu, 24 Apr 2014 09:26:14 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E334F1A01E5 for ; Thu, 24 Apr 2014 09:26:13 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id e16so1881720lan.41 for ; Thu, 24 Apr 2014 09:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=bQxzbcb66YskoQItNVgn2kfRGDvpqqiXcAVy4Uw+MPM=; b=QVVzYivzmDKduRIX/IJqU2w/LPQ20Qm7oZ/zQBhIEbf3nyHgN2KofH7tUBOO6r+8f2 DfojPznowKalTxugzroEcypCOX17DBhtcqHbX85OKkwW98nsjPT9Lno6JwRvKOgvrmL6 RIVbttszperYnMn2tnP6G4ApkBDXgl02TJ+FfbzMQnK+UEVpUAcjQZBRMVJDZzRYID2J 1YRBeldYzPyKD9KRjhc/cGaYaZjm0+8bGZBfYbp8uN33tMHyJak/AW7ro7NNV3eWMhcB Mj+Azau2wklkMbKNkI0S+tOWSd/gLkAJhABAeko4w70ekClIIq6tCJRRLVyTYiW43+4l Y2rQ== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr1909557lac.0.1398356767117; Thu, 24 Apr 2014 09:26:07 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Thu, 24 Apr 2014 09:26:07 -0700 (PDT) Date: Thu, 24 Apr 2014 11:26:07 -0500 Message-ID: From: Behcet Sarikaya To: sfc@ietf.org Content-Type: multipart/alternative; boundary=001a113484bc5f957f04f7cc4e58 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Mf95xl-M9JRYpv21Kom-s5d0N1s Subject: [sfc] Recallling the post X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:26:16 -0000 --001a113484bc5f957f04f7cc4e58 Content-Type: text/plain; charset=UTF-8 Hi all, The author wishes to recall the following email posted on the list yesterday. Behcet - *From*: Behcet Sarikaya > - *To*: "Joel M. Halpern" >, sfc at ietf.org - *Cc*: Xueli > - *Date*: Wed, 23 Apr 2014 16:40:10 -0500 - *In-reply-to*: <5356720A.4080302@joelhalpern.com> - *References*: <20140421195656.18585.79150.idtracker@ietfa.amsl.com> < 5356720A.4080302@joelhalpern.com> - *List-id*: Network Service Chaining ------------------------------ Hi Joel, Thanks for your comments. I think you forgot to cc it to the list :-) On Tue, Apr 22, 2014 at 8:43 AM, Joel M. Halpern wrote: > Reading this, it appears that youa re asserting that service functions in > a service chain environment must be able to decrypt subscriber encrypted > https traffic. > > I agree that encryption makes applying content functions harder. > > But the IETF is not going to mandate operator based decryption of > end-to-end encrypted content. Doing so would seem to require that we > violate existing RFCs and weaken the effective crypto. For example, it is > simply not acceptable to require that customers accept operator > certificates in place of content provider certificates. (Some customers > may choose to accept those, but we clear can not mandate such.) > > In fact we carried this text from Broadband Forum Document SD-326 on flexible service chaining, Section 6.2.2. We did not intend to hint on an IETF solution. SD-326 also says that the solution is out of scope. > Separately, the content of the document does not seem to match the title. > Based on the title I was expecting to see a discussion of the problems > caused by address sharing. (Such problems are part of the motivation for > subscriber identification metadata.) But instead there is a description of > some use cases for residential network service, without any discussion I > could find of address sharing. What did I miss. > > I think the description is there but may be it needs to be clarified which we will do in the next version. Regards, Behcet Yours, Joel On 4/21/14, 3:56 PM, internet-drafts at ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identification Problem in Service Function Chaining Use Cases Authors : Li Xue Behcet Sarikaya Filename : draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt Pages : 7 Date : 2014-04-21 Abstract: The purpose of this document is to present host identification problem due to the address and prefix sharing in service function chaining. So far we have identified this problem in the two use cases of the parental control service and offloading service but it is likely that more use cases can be identified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-xue-sfc-address-sharing-in-sfc-use-cases-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 at 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 --001a113484bc5f957f04f7cc4e58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The author wishes to recall= the following email posted on the list yesterday.

Behcet
<= div>
Hi Joel,

Thanks for your comments. I think you forgot to = cc it to the list :-)


On Tue, Apr 22, 2014 at 8:43 AM, Joel M. H= alpern <jmh at joelhalpern.com> wr= ote:
Reading this, it appears that youa re asserting that service functions in a=20 service chain environment must be able to decrypt subscriber encrypted=20 https traffic.

I agree that encryption makes applying content functions harder.

But the IETF is not going to mandate operator based decryption of=20 end-to-end encrypted content. =C2=A0Doing so would seem to require that we= =20 violate existing RFCs and weaken the effective crypto. =C2=A0For example, i= t=20 is simply not acceptable to require that customers accept operator=20 certificates in place of content provider certificates. =C2=A0(Some custome= rs may choose to accept those, but we clear can not mandate such.)


In fact we carried this text from Broa= dband Forum Document SD-326 on flexible service chaining, Section 6.2.2.
We did not intend to hint on an IETF solution. SD-326 also says= that the solution is out of scope.
=C2=A0
Separately, the content of the document does not seem to match the=20 title. =C2=A0Based on the title I was expecting to see a discussion of the= =20 problems caused by address sharing. =C2=A0(Such problems are part of the=20 motivation for subscriber identification metadata.) =C2=A0But instead there= =20 is a description of some use cases for residential network service,=20 without any discussion I could find of address sharing. =C2=A0What did I=20 miss.


I think the description is there but m= ay be it needs to be clarified which we will do in the next version.
Regards,

Behcet
Yours,
Joel

On 4/21/14, 3:56 PM, internet-drafts at ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Host Identification Problem in Service Function Chaining Use Cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Li = Xue
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Behcet Sarikaya
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-xue= -sfc-address-sharing-in-sfc-use-cases-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-04-21

Abstract:
=C2=A0 =C2=A0 The purpose of this document is to present host identificatio= n
=C2=A0 =C2=A0 problem due to the address and prefix sharing in service func= tion
=C2=A0 =C2=A0 chaining. =C2=A0So far we have identified this problem in the= two use
=C2=A0 =C2=A0 cases of the parental control service and offloading service = but it
=C2=A0 =C2=A0 is likely that more use cases can be identified.


The IETF datatracker status page for this draft is:
https://datatracker.ie= tf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html= /draft-xue-sfc-address-sharing-in-sfc-use-cases-00


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

--001a113484bc5f957f04f7cc4e58-- From nobody Thu Apr 24 09:40: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 AEE451A01E1 for ; Thu, 24 Apr 2014 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Rr-kVI-2UZLS for ; Thu, 24 Apr 2014 09:40:48 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 173D31A02B5 for ; Thu, 24 Apr 2014 09:40:47 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id 10so2149420lbg.25 for ; Thu, 24 Apr 2014 09:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DzPim9pTms66h9w6oyoqX9FF09XC0sN3ekKZqr8lK1E=; b=wv/lqQ8RQZkQZTNG0/3mZjwPcJGpT5rDBQvOFZ0A3WO2igMqqYVD8QgoJljTJhNS68 Bke40gb1OtYAs9/LP6zwFUb+NUU6VZk4XVBJxraX39lJWuuMuziAjKqiOIWPp+MWXNUC bnwUuX1qlI4pMOSX9zTA82bp6TBkvgUykLWCu4XTldK1tiEYQBJ32hvb+4x0mdNkl3Q3 YQerqAy9tpeRkep+nJshvgEuaaLQZ5SjOoQFFn7UPvjKrc+1OUGIs61QcGN8TKvNtDB8 NMg9myeArtoznu6KOer4gmYLzFF/aCs8pbJ9uVPRpfwtfcOuFpzondBpAGMJiyqdtYsp LTqw== MIME-Version: 1.0 X-Received: by 10.152.21.200 with SMTP id x8mr1175756lae.58.1398357641268; Thu, 24 Apr 2014 09:40:41 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Thu, 24 Apr 2014 09:40:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 11:40:41 -0500 Message-ID: From: Behcet Sarikaya To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=089e0158aef47a0ff904f7cc8273 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mS8jzXESmBZwUhiLA8qdnGvJ-0k Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:40:49 -0000 --089e0158aef47a0ff904f7cc8273 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I think there is conflict in what Figure 1 says and what Figure 6 says regarding the NAT function. As far as I know, 3GPP specs recommends placing NAT or NAT44 function at PGW. I understand that as being before Gi-LAN. If this could be clarified, please. Regards, Behcet On Fri, Apr 18, 2014 at 5:29 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending > 2nd May 2014. > > Please respond to the SFC mailing list with any statements of approval > or disapproval. > > Please note: > > 1. This is not WG Last Call. The document is not final, and the WG is > expected to modify the document=E2=80=99s content until there is WG co= nsensus that > the content is solid. Therefore, please don=E2=80=99t 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 conce= rns. > 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 them. > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --089e0158aef47a0ff904f7cc8273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I think ther= e is conflict in what Figure 1 says and what Figure 6 says regarding the NA= T function.

As far as I know, 3GPP specs recommends placing NA= T or NAT44 function at PGW. I understand that as being before Gi-LAN.

If this could be clarified, please.

Regards,

=
Behcet


On Fri, Apr 18, 2014 at 5:29 PM, Jim Guichard (jguichar) <jguich= ar@cisco.com> wrote:
Dear WG:

This message begins a two week call for WG adoption of the document=C2= =A0http://www.ietf.org/id/draft-haeffner-sfc-use-case= -mobility-01.txt=C2=A0ending 2nd May 2014.=C2=A0

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=E2=80=99s content until there is WG consensus t= hat the content is solid. Therefore, please don=E2=80=99t oppose adoption j= ust because you want to see changes to its content.
  2. If you have objections to adoption of the document, please state your r= easons 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 them.=C2=A0

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


--089e0158aef47a0ff904f7cc8273-- From nobody Thu Apr 24 14:26: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 AC9A51A03F1 for ; Thu, 24 Apr 2014 14:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 g3K_Btp78BQj for ; Thu, 24 Apr 2014 14:26:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3B771A0165 for ; Thu, 24 Apr 2014 14:26:03 -0700 (PDT) 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 BGB13903; Thu, 24 Apr 2014 21:25:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 22:24:55 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 22:25:54 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 14:25:45 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: Suggestion to draft-boucadair-sfc-requirements-04 Thread-Index: Ac9gA8EBGGbFmEDAT+ugVpKoBP5k5w== Date: Thu, 24 Apr 2014 21:25:45 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CFD182@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.47.150.240] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645CFD182dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CI5Tavpku7lw6zASGJ0OG2aGCJs Subject: [sfc] Suggestion to draft-boucadair-sfc-requirements-04 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, 24 Apr 2014 21:26:07 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645CFD182dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mohamed, et al, The draft listed 30 plus requirements under one category "Detailed Requirem= ent List". I think that requirement list should be grouped by category. Usi= ng RFC 5654 as a good reference, Service Chain should at least have the fol= lowing category: - Service Chain General Requirement - Data Plane requirement o Encapsulation requirement o Service Function identification requirement o etc - Control Plane requirement - Protection & Restoration requirement - OAM requirement Yours, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645CFD182dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mohamed, et al,

 

The draft listed 30 plus requirements under one cate= gory “Detailed Requirement List”. I think that requirement list= should be grouped by category. Using RFC 5654 as a good reference, Service= Chain should at least have the following category:

 

-     &= nbsp;    Service Chain General Requirement

-     &= nbsp;    Data Plane requirement

o   Encapsulation requirement

o   Service Function identification requirement<= o:p>

o   etc

-     &= nbsp;    Control Plane requirement

-     &= nbsp;    Protection & Restoration requirement=

-     &= nbsp;    OAM requirement

 

Yours,

 

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645CFD182dfweml701chmchi_-- From nobody Thu Apr 24 15:56: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 9028C1A041A for ; Thu, 24 Apr 2014 15:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 sNRUP-Aq8m_H for ; Thu, 24 Apr 2014 15:56:08 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) by ietfa.amsl.com (Postfix) with ESMTP id AE68C1A0412 for ; Thu, 24 Apr 2014 15:56:08 -0700 (PDT) Received: from [192.168.10.22] (KYNfb-06p1-194.ppp11.odn.ad.jp [219.66.229.194]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s3OMtolD012590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 18:55:52 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-87E812CA-FA8D-404F-8B1F-A6DAEF68458C Message-Id: <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> X-Mailer: iPad Mail (11D167) From: Changcheng Huang Date: Fri, 25 Apr 2014 07:55:50 +0900 To: "Jim Guichard (jguichar)" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FbacX9xqOSxf_DQzOcWcVPERZTM Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 24 Apr 2014 22:56:11 -0000 --Apple-Mail-87E812CA-FA8D-404F-8B1F-A6DAEF68458C Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable I don't support the adoption of this document. I think it has not covered so= me key aspects of datacenter. It is well known that datacenter services can b= e provided in different levels which include IaaS, PaaS, and SaaS. This docu= ment has not addressed use cases under these different scenarios, nor has it= discussed the possible business relationships that may have an impact on SFC= . We have proposed recursive service in our contribution (draft-huang) which= addresses these use cases and how they may be supported.=20 Best regards, Chang ------------ Changcheng Huang > On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" wrote: >=20 > Dear WG: >=20 > This message begins a two week call for WG adoption of the document http:/= /www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014.=20= >=20 > Please respond to the SFC mailing list with any statements of approval or d= isapproval. >=20 > Please note: > This is not WG Last Call. The document is not final, and the WG is expecte= d to modify the document=A1=AFs content until there is WG consensus that the= content is solid. Therefore, please don=A1=AFt oppose adoption just because= you want to see changes to its content. > If you have objections to adoption of the document, please state your reas= ons why, and explain what it would take to address your concerns. > If you have issues with the content, by all means raise those issues and w= e can begin a dialog about how best to address them.=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-87E812CA-FA8D-404F-8B1F-A6DAEF68458C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't support the adoption of this d= ocument. I think it has not covered some key aspects of datacenter. It is we= ll known that datacenter services can be provided in different levels which i= nclude IaaS, PaaS, and SaaS. This document has not addressed use cases under= these different scenarios, nor has it discussed the possible business relat= ionships that may have an impact on SFC. We have proposed recursive service i= n our contribution (draft-huang) which addresses these use cases and how the= y may be supported. 

Best regards,
<= br>
Chang

------------
Changcheng Huang

On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nbs= p;htt= p://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd M= ay 2014. 

Please respond to the SFC mailing list with any statements of approval o= r disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expec= ted to modify the document=E2=80=99s content until there is WG consensus tha= t the content is solid. Therefore, please don=E2=80=99t oppose adoption just= because you want to see changes to its content.
  2. If you have objecti= ons to adoption of the document, please state your reasons why, and explain w= hat it would take to address your concerns.
  3. If you have issues with t= he content, by all means raise those issues and we can begin a dialog about h= ow best to address them. 
____________________= ___________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc
= --Apple-Mail-87E812CA-FA8D-404F-8B1F-A6DAEF68458C-- From nobody Thu Apr 24 16:22: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 119DF1A02A1 for ; Thu, 24 Apr 2014 16:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 D6xiTFT36MOj for ; Thu, 24 Apr 2014 16:22:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC491A0294 for ; Thu, 24 Apr 2014 16:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5648; q=dns/txt; s=iport; t=1398381722; x=1399591322; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=orhfeFAoq6lcf+BgQeh8/THUPhll97NUmGehXN5Oarw=; b=DfnRq2JDMK5J6vo3hrElswbkSpE/+b+Kxnua9X4R75zC8aUyW47O0aTk EWuKsr3qDTlFtBPEBOWGuHd3gAuNkH6sSslO9AmVl94NVrU0MISpk1qSK bw4sTngvIwob+TAHaMqiZajISd7nxXwLwwuKf8cm9B5F5tKt/uX7qup7q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFACicWVOtJV2a/2dsb2JhbABZgwZPvTyHOIEeFnSCJgEBBAEBARpRBAcQAgEIBDsHJwsUEQIEDgUJiDgNyxkXjlUEB4MkgRUEhTmTQJJZgzE X-IronPort-AV: E=Sophos;i="4.97,922,1389744000"; d="scan'208,217";a="320138446" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 24 Apr 2014 23:22:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3ONM0k0018747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 23:22:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 18:22:00 -0500 From: "Jim Guichard (jguichar)" To: Changcheng Huang Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZshvdIA//+zfQ4= Date: Thu, 24 Apr 2014 23:22:00 +0000 Message-ID: <4009BCE6-7F80-4E7B-854F-422B436ACB0D@cisco.com> References: , <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> In-Reply-To: <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4009BCE67F804E7B854F422B436ACB0Dciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/aJMKOmf98y6Tm62Rc22CQpKXZ30 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 24 Apr 2014 23:22:11 -0000 --_000_4009BCE67F804E7B854F422B436ACB0Dciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Chang, Thanks for you inputs. Please note however that the document *if* adopted i= s not final and the WG is fully expected to modify its content until there = is consensus that all of the major components have been addressed. Please c= ontinue to work with the authors to incorporate your suggestions if appropr= iate. Sent from my iPhone On Apr 24, 2014, at 6:56 PM, "Changcheng Huang" > wrote: I don't support the adoption of this document. I think it has not covered s= ome key aspects of datacenter. It is well known that datacenter services ca= n be provided in different levels which include IaaS, PaaS, and SaaS. This = document has not addressed use cases under these different scenarios, nor h= as it discussed the possible business relationships that may have an impact= on SFC. We have proposed recursive service in our contribution (draft-huan= g) which addresses these use cases and how they may be supported. Best regards, Chang ------------ Changcheng Huang On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4009BCE67F804E7B854F422B436ACB0Dciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Chang,

Thanks for you inputs. Please note however that the document *if* adop= ted is not final and the WG is fully expected to modify its content until t= here is consensus that all of the major components have been addressed. Ple= ase continue to work with the authors to incorporate your suggestions if appropriate.

Sent from my iPhone

On Apr 24, 2014, at 6:56 PM, "Changcheng Huang" <huang@sce.carleton.ca> wrote:

I don't support the adoption of this document. I think it has not cove= red some key aspects of datacenter. It is well known that datacenter servic= es can be provided in different levels which include IaaS, PaaS, and SaaS. = This document has not addressed use cases under these different scenarios, nor has it discussed the possib= le business relationships that may have an impact on SFC. We have proposed = recursive service in our contribution (draft-huang) which addresses these u= se cases and how they may be supported. 

Best regards,

Chang

------------
Changcheng Huang

On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_4009BCE67F804E7B854F422B436ACB0Dciscocom_-- From nobody Thu Apr 24 17:33: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 8A5651A0448 for ; Thu, 24 Apr 2014 17:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.172 X-Spam-Level: X-Spam-Status: No, score=-7.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 zxxLkZdxL5f0 for ; Thu, 24 Apr 2014 17:33:23 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 154411A02B8 for ; Thu, 24 Apr 2014 17:33:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="108687556" X-IPAS-Result: ApAFADD7RVPAqArr/2dsb2JhbABZgkJ/V7sfgSQbhzWBN3SCJQEBAQEDAQEBGlEEBxACAQgNBAMBAigHJwsUCQgCBAENBQmIAMwQF45bDQQHBoQyBJoThUaOd4Ir Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Apr 2014 00:33:17 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 24 Apr 2014 17:33:16 -0700 From: Sumandra Majee To: Changcheng Huang , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsh31kA//+l3gA= Date: Fri, 25 Apr 2014 00:33:16 +0000 Message-ID: References: <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> In-Reply-To: <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> 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.236] Content-Type: multipart/alternative; boundary="_000_CF7EFB071E8D3smajeef5com_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FBCJV1FqMOTi-nO59WxpYUKa-F8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 00:33:25 -0000 --_000_CF7EFB071E8D3smajeef5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Are you referring to http://tools.ietf.org/html/draft-huang-sfc-service-forwarding-label-00 If so I have a few questions. From: Changcheng Huang = > Date: Thursday, April 24, 2014 at 3:55 PM To: "Jim Guichard (jguichar)" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 I don't support the adoption of this document. I think it has not covered s= ome key aspects of datacenter. It is well known that datacenter services ca= n be provided in different levels which include IaaS, PaaS, and SaaS. This = document has not addressed use cases under these different scenarios, nor h= as it discussed the possible business relationships that may have an impact= on SFC. We have proposed recursive service in our contribution (draft-huan= g) which addresses these use cases and how they may be supported. Best regards, Chang ------------ Changcheng Huang On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CF7EFB071E8D3smajeef5com_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Are you referring to

If so I have a few questions.

From: Changcheng Huang <huang@sce.carleton.ca>
Date: Thursday, April 24, 2014 at 3= :55 PM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com> Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] Call for adoptio= n of draft-kumar-sfc-dc-use-cases-01

I don't support the adoption of this document. I think it has not cove= red some key aspects of datacenter. It is well known that datacenter servic= es can be provided in different levels which include IaaS, PaaS, and SaaS. = This document has not addressed use cases under these different scenarios, nor has it discussed the possib= le business relationships that may have an impact on SFC. We have proposed = recursive service in our contribution (draft-huang) which addresses these u= se cases and how they may be supported. 

Best regards,

Chang

------------
Changcheng Huang

On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
 --_000_CF7EFB071E8D3smajeef5com_-- From nobody Thu Apr 24 17:41: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 A760B1A0447 for ; Thu, 24 Apr 2014 17:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 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.272, 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 hAvWI4ixeN_C for ; Thu, 24 Apr 2014 17:41:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 635A81A0442 for ; Thu, 24 Apr 2014 17:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30845; q=dns/txt; s=iport; t=1398386475; x=1399596075; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lc6S8sLgFw1Kxswiq4ZSYHdEl45Cm9RbtGk+gh58GHU=; b=TJp80aER9S1pgQZ305AIwErZ5bw8a+BaFNbI6l1RgcIc1I7hrpsMrDYF Ls4/ndlUtWa1wmOGrV7AiFzdH4HpXqWw13R9ktDkckpih4LEPHg214BKQ k5ndN9qYf5hN08/2jbbeh4R2qoPSMPXtv6VtcHmmOThcZ2ectckMsyELp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFADauWVOtJA2D/2dsb2JhbABPCoJCRE9XxB2BHhZ0giUBAQEEHRA+AxsCAQgRAQIBAQEhAQYHMhQDBggCBAESiEHLFxeJN4RABgsBPxcBhDkEmHmSWYMxgXI5 X-IronPort-AV: E=Sophos;i="4.97,923,1389744000"; d="scan'208,217";a="317158427" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 25 Apr 2014 00:41:14 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3P0fEHu003479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 00:41:14 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 19:41:14 -0500 From: "Surendra Kumar (smkumar)" To: "Hongyu Li (Julio)" , Lucy yong , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of SFC use case documents Thread-Index: AQHPW1K8K2mTLR48uE+GohTdExdCc5sX9OdggAVYz0CABBg5gA== Date: Fri, 25 Apr 2014 00:41:14 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@dfweml701-chm.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E9F312A@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E9F312A@SZXEMA509-MBX.china.huawei.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.21.120.65] Content-Type: multipart/alternative; boundary="_000_CF7EFB9B3C4A5smkumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ldIdXq0PoA3e7O6aTgqbGF8gpI0 Subject: Re: [sfc] Progression of SFC use case documents 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, 25 Apr 2014 00:41:24 -0000 --_000_CF7EFB9B3C4A5smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Inline. From: "Hongyu Li (Julio)" > Date: Tuesday, April 22, 2014 1:58 AM To: Lucy yong >, "Jim Gui= chard (jguichar)" >, "sfc@iet= f.org" > Subject: Re: [sfc] Progression of SFC use case documents Hi Chairs, I support Lucy=92s comment. draft-kumar-sfc-dc-use-case has a fancy name, b= ut not so fancy use cases. Snipped from Chairs=92 email: SK> Our goal is to capture the use cases in enterprise DCs that highlight t= he challenges in deploying legacy service chaining and bring out the requir= ements for SFC architecture with examples. 1. Adopt a small number of WG documents (initially 2) that are applic= able to specific environments and that can be worked on independently by me= mbers of the WG that have the necessary expertise for that environment, Both mobile and fixed network may put their Service Functions in a virtual = environment, which is very possibly a datacenter. So, draft-kumar-sfc-dc-u= se-case has a great overlap with other use case drafts including, even thou= gh you want to have =93specific environments=94 and clean cuts between them= . SK> In fact I would go a step further and say, the concepts underlying all = of them are the same - the reason all use cases are in this WG. The require= ments on the other hand are indeed different, specifically when contrasted = with Mobile SP. Although NFV is shining some light on SFC through Mobility use cases in rec= ent days, enterprise use cases have existed for a very long time. There are= a lot more enterprise deployments, small & large, than mobile SP. We would= be better served by not ignoring the vast majority of the SFC deployments,= in major enterprise DCs, pretty much everywhere. and that can work directly with the applicable SDOs on incorporating releva= nt content. There was a question on the mailing list asking what are the SDOs draft-kum= ar-sfc-dc-use-case is corresponding to, but no answer was posted so far. SK> Do you have a suggestion for an SDO for enterprise DC ? Surendra. So, it seems draft-kumar-sfc-dc-use-case doesn=92t serve your purpose at al= l. BR, Hongyu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Saturday, April 19, 2014 7:06 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Progression of SFC use case documents Dear Chairs, People including myself did not voice a single document to capture all poss= ible use cases because there is no need to do that. We suggested capturing = all necessary use cases that help driving the architecture and requirement = development. Giving the situation, I support adopting draft-haeffner-sfc-use-case-moblit= y as WG draft. This is because a large portion of SFC use cases are in Mobi= le applications; and the draft describes many unique ways to use SFC. It is= good to have one draft to cover Mobile area. IMO: draft-kumar-sfc-dc-use-cases does not depict unique SFC cases from a g= eneral SFC case except the SFC applications location is in data centers. Th= us these cases can be easily merged into the general use case draft. So we = have another use case draft for the rest. Regards, Lucy Dear WG: There has been much discussion both on the list and during our face-to-face= meetings about how best to progress use case documents within the WG. Ther= e are clearly arguments for both of the following approaches: 1. A single document that captures all of the possible use cases. 2. A small number of targeted documents that are focused on a particular= subset of the overall problem space (such as broadband, mobility, and data= center). But, we can=92t choose both. In considering these approaches, the chairs re= cognize that there are benefits to having a single document, but do not bel= ieve having just one document is workable in this case. Nor is there consen= sus for having a single document. Therefore, we will pursue the following = approach going forward: 1. Adopt a small number of WG documents (initially 2) that are applicabl= e to specific environments and that can be worked on independently by membe= rs of the WG that have the necessary expertise for that environment, and th= at can work directly with the applicable SDOs on incorporating relevant con= tent. 2. Continue to leave open the possibility of adopting a high-level use c= ase document that serves as a =93catch all=94 for use cases that do not mer= it their own document or are not captured in the content of more focused us= e case documents. However, before taking on such a document, the WG will ne= ed to understand in more detail what the content would be and that the cont= ent justifies having such a document. Such a document should not duplicate = material that is covered in other documents. To facilitate the above direction the chairs will take the following steps: 1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and draf= t-kumar-sfc-dc-use-cases as WG documents. 2. Encourage the authors to continue to work on refinement of draft-liu-= sfc-use-cases. The authors of that document should update their draft to re= move any duplication of material covered in other documents as well as iden= tify content that is not covered elsewhere. We hope that this approach will allow the WG to move forward and also provi= de enough flexibility to allow use cases to evolve independently, with dire= ct interaction with the appropriate SDOs. Thanks, Jim & Thomas --_000_CF7EFB9B3C4A5smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Inline.

From: "Hongyu Li (Julio)"= <hongyu.li@huawei.com> Date: Tuesday, April 22, 2014 1:58 = AM
To: Lucy yong <lucy.yong@huawei.com>, "Jim Guichard (jg= uichar)" <jguichar@cisco.com<= /a>>, "sfc@ietf.org" <<= a href=3D"mailto:sfc@ietf.org">sfc@ietf.org>
Subject: Re: [sfc] Progression of S= FC use case documents

Hi Chairs,

 =

I support Lucy=92= s comment. draft-kumar-sfc-dc-use-case has a fancy name, but not so fancy u= se cases. Snipped from Chairs=92 email:
SK> Our goal is to capture the use cases in enterprise DCs th= at highlight the challenges in deploying legacy service chaining and bring = out the requirements for SFC architecture with examples.

1.       Adopt a small nu= mber of WG documents (initially 2) that are applicable to specific environm= ents and that can be worked on independently by members of the WG that have the necessary expertise for that environmen= t,

Both mobile and f= ixed network may put their Service Functions in a virtual environment, whic= h is very possibly  a datacenter. So, draft-kumar-sfc-dc-use-case has a great overlap with other use case drafts= including, even though you want to have =93specific environments=94 and cl= ean cuts between them.
SK> In fact I would go a step further and say, t= he concepts underlying all of them are the same - the reason all use cases = are in this WG. The requirements on the other hand are indeed different, sp= ecifically when contrasted with Mobile SP. 
Although NFV is shining some light on SFC through M= obility use cases in recent days, enterprise use cases have existed for a v= ery long time. There are a lot more enterprise deployments, small & lar= ge, than mobile SP. We would be better served by not ignoring the vast majority of the SFC deployments, in major = enterprise DCs, pretty much everywhere.

There was a quest= ion on the mailing list asking what are the SDOs draft-kumar-sfc-dc-use-cas= e is corresponding to, but no answer was posted so far.
SK> Do you have a suggestion for an SDO for ente= rprise DC ?

Surendra.

 =

So, it seems draf= t-kumar-sfc-dc-use-case doesn=92t serve your purpose at all.

 =

BR,

Hongyu=

 =

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Saturday, April 19, 2014 7:06 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] Progression of SFC use case documents<= /span>

 

Dear Chairs,

 

People includ= ing myself did not voice a single document to capture all possible use case= s because there is no need to do that. We suggested capturing all necessary use cases that help driving the archi= tecture and requirement development.

 

Giving the si= tuation, I support adopting draft-haeffner-sfc-use-case-moblity as WG draft= . This is because a large portion of SFC use cases are in Mobile applications; and the draft describes many unique = ways to use SFC. It is good to have one draft to cover Mobile area.

 

IMO: draft-ku= mar-sfc-dc-use-cases does not depict unique SFC cases from a general SFC ca= se except the SFC applications location is in data centers. Thus these cases can be easily merged into the general= use case draft. So we have another use case draft for the rest.=

 

Regards,=

Lucy

 

Dear WG:

 

There has been much discussi= on both on the list and during our face-to-face meetings about how best to = progress use case documents within the WG. There are clearly arguments for both of the following approaches:=

  1. A single document that captures all of the possible use cases.
  2. A small number of targeted documents that are focused on a partic= ular subset of the overall problem space (such as broadband, mobility, and = data center).

But, we can=92t choose both.= In considering these approaches, the chairs recognize that there are benef= its to having a single document, but do not believe having just one document is workable in this case. Nor is ther= e consensus for having a single document.  Therefore, we will pursue t= he following approach going forward:

  1. Adopt a small number of WG documents (initially 2) that are appli= cable to specific environments and that can be worked on independently by m= embers of the WG that have the necessary expertise for that environment, and that can work directly with the applic= able SDOs on incorporating relevant content.
  2. Continue to leave open the possibility of adopting a high-level u= se case document that serves as a =93catch all=94 for use cases that do not= merit their own document or are not captured in the content of more focused use case documents. However, before taking = on such a document, the WG will need to understand in more detail what the = content would be and that the content justifies having such a document. Suc= h a document should not duplicate material that is covered in other documents. 
    3. <= /ol>

    To facilitate the above dire= ction the chairs will take the following steps:

    1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and = draft-kumar-sfc-dc-use-cases as WG documents.
    2. Encourage the authors to continue to work on refinement of draft-= liu-sfc-use-cases. The authors of that document should update their draft t= o remove any duplication of material covered in other documents as well as identify content that is not covered= elsewhere. 

    We hope that this approach w= ill allow the WG to move forward and also provide enough flexibility to all= ow use cases to evolve independently, with direct interaction with the appropriate SDOs.

     

    Thanks,

     

    Jim & Thomas<= /span>

 --_000_CF7EFB9B3C4A5smkumarciscocom_-- From nobody Thu Apr 24 18:10: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 C1CF91A0182 for ; Thu, 24 Apr 2014 18:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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.272, 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 wWzdJ9RSjaTF for ; Thu, 24 Apr 2014 18:10:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id AA8BE1A0173 for ; Thu, 24 Apr 2014 18:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10451; q=dns/txt; s=iport; t=1398388236; x=1399597836; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YUfeAJTXwsQeMDeoT5l2mCsK7aOMmOUkIsstCNWbpOc=; b=N1JrnhHPy9TPl63UpOVlJL5DZISOc+Kq3o5DDgMQQh1I60Yj1y8jEnHp ccBK1FWRt8KXAfH4e600NYNRhkgvv6qb6RbwzkTMQuZJZFOYuDixHgUNf ZeQfcyTFxx1nj6wlbaWpW+Tx9+SuoZXMzLf41GNVE6NzJbYZOioh4NQu/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAMO0WVOtJV2Z/2dsb2JhbABZgkJET1fEHYEeFnSCJQEBAQQdURsCAQYCDgMDAQIoBzIUCQgCBAESCYg4DYsnv2AXji4aGAaEMwSYeZJZgzGCKw X-IronPort-AV: E=Sophos; i="4.97,923,1389744000"; d="scan'208,217"; a="38564677" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 25 Apr 2014 01:10:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3P1Aacm015442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 01:10:36 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 20:10:35 -0500 From: "Surendra Kumar (smkumar)" To: Sumandra Majee , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPX1ZfU8UhsrhhTUWWEhfLxMVVkZshZhqA Date: Fri, 25 Apr 2014 01:10:34 +0000 Message-ID: References: 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: [10.21.120.65] Content-Type: multipart/alternative; boundary="_000_CF7EFD753C4C5smkumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vV23etSAq-7JBIivbfaSPi4tm1Y Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 01:10:45 -0000 --_000_CF7EFD753C4C5smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Sumandra! As you seem to have noticed, the primary focus is indeed enterprise. Howeve= r, there are a lot of commonalities with SP DCs and is the reason why it is= extended to include SPs. I hear you on the policies. At the same time I've= seen the swings from per-resource on one end to the per-user at the other = end. There are use cases involving per-user policy even in the enterprise = =96 Fine grain firewalls (DC de-perimetrization) as one example, where poli= cies can be enforced at the user and URL level. Regarding 5-tuple in Mobile, five tuples do change. I can think of Mobile S= Ps using private addresses and NATing them towards the Internet. Look forward to any specific comments and suggestions you may have and we w= ill reflect them in the next revision. Surendra. From: Sumandra Majee > Date: Wednesday, April 23, 2014 5:44 PM To: "Jim Guichard (jguichar)" >, "sfc@ietf.org" > Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 I support the adoption but I have following observations. 1) Datacenter encompasses a lot of application and varied vertical marke= t. I would like to see this focus on the enterprise and perhaps the cloud D= C use cases. Service providers use data center too, but the policies are of= ten applied per subscriber and per resource (URL), per application. Enterpr= ise datacenter policy may not involve per user policy (I think most will no= t but it does involve a group of users). There are layers of ADC in the enterprise in the form of, L4 distribution =97=97=97=97 ADC 1(with a unicast VIP1) [APP resource] = =97=97=97=97=97 ADC2 (VIP2 : APP resource 2). These can be viewed as same= instance or sometimes NOT. 2) In the mobile DC when flows are threaded thru a series of VAS, the 5 tu= ple remain unchanged. That is not the case in enterprise when there is a se= rver to server communication on behalf of a client. The east west traffic = in cloud DC is quite unruly since the changes are made often and new servic= es are created by DevOps every so often. I think this is a significantly d= ifferent from SP datacenter (where scale matters but number of unique appli= cations are relatively small) and should be covered in detail. I would rather see the focus on enterprise/cloud (call this draft-enterpris= e-=85.) and cover the uniqueness of that piece of land than a generic DC. Regards. Sumandra From: "Jim Guichard (jguichar)" > Date: Friday, April 18, 2014 at 3:31 To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF7EFD753C4C5smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks Sumandra!

As you seem to have noticed, the primary focus is indeed enterprise. H= owever, there are a lot of commonalities with SP DCs and is the reason why = it is extended to include SPs. I hear you on the policies. At the same time= I've seen the swings from per-resource on one end to the per-user at the other end.  There are use cases inv= olving per-user policy even in the enterprise =96 Fine grain firewalls (DC = de-perimetrization) as one example, where policies can be enforced at the u= ser and URL level.

Regarding 5-tuple in Mobile, five tuples do change. I can think of Mob= ile SPs using private addresses and NATing them towards the Internet.

Look forward to any specific comments and suggestions you may have and= we will reflect them in the next revision.

Surendra.

From: Sumandra Majee <S.Majee@F5.com>
Date: Wednesday, April 23, 2014 5:4= 4 PM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Call for adoptio= n of draft-kumar-sfc-dc-use-cases-01

I support the adoption but I have following observations.

  1)  Datacenter encompasses a lot of application and varied= vertical market. I would like to see this focus on the enterprise and perh= aps the cloud DC use cases. Service providers use data center too, but the = policies are often applied per subscriber and per resource (URL), per application. Enterprise datacenter policy may = not involve per user policy (I think most will not but it does involve a gr= oup of users).  

There are layers of ADC in the enterprise in the form of,
   L4 distribution  =97=97=97=97 ADC 1(with a unicast V= IP1) [APP resource]  =97=97=97=97=97  ADC2 (VIP2 : APP resource 2= ). These can be viewed as same instance or sometimes NOT. 

2) In the mobile DC when flows are threaded thru a series of VAS, &nbs= p;the 5 tuple remain unchanged. That is not the case in enterprise when the= re is a server to server communication on behalf of a client.  The eas= t west traffic in cloud DC is quite unruly since the changes are made often and new services are created by DevOps &n= bsp;every so often. I think this is a significantly different from SP datac= enter (where scale matters but number of unique applications are relatively= small) and should be covered in detail.

I would rather see the focus on enterprise/cloud (call this draft-ente= rprise-=85.) and cover the uniqueness of that piece of land than a generic = DC.

Regards.

Sumandra

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, April 18, 2014 at 3:3= 1 
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-kumar-sfc-dc-use-cases-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
 --_000_CF7EFD753C4C5smkumarciscocom_-- From nobody Thu Apr 24 18:19: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 8F2FE1A033E for ; Thu, 24 Apr 2014 18:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 ai-BD1CVtrH1 for ; Thu, 24 Apr 2014 18:18:58 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id BB52B1A0197 for ; Thu, 24 Apr 2014 18:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3667; q=dns/txt; s=iport; t=1398388732; x=1399598332; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4gR+IvmYY/xhY8XAt8GGYgS3DON5F2vD3H3d4fMeAWY=; b=XDsC2O8AO65CJOB0GAeZCjzcB/TMEMFBxbDtg6P67wPunOFH3uGQMCPX UZ9c3f6n/eERvJS1Ys0q802TpKBma3fgym1WKkjhM+M2LiRM6XlHnjziA UP+hNleAQqaeAm94DVeejvQE0YtfpmBp8yeGGR1HgHO42O+joghcZttlr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFACe3WVOtJA2I/2dsb2JhbABZgwZPV7xlhziBHRZ0giUBAQEEAQEBGlELEAIBBgIOAwECAQIBLicLFwYIAgQBDQUJiDgNiyC/YReOJggrBwaEMwSYeZJZgzGCKw X-IronPort-AV: E=Sophos;i="4.97,923,1389744000"; d="scan'208";a="38566284" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 25 Apr 2014 01:18:52 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3P1IqgX032496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 01:18:52 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 20:18:51 -0500 From: "Surendra Kumar (smkumar)" To: Barry Greene , Sumandra Majee Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPX1ZfU8UhsrhhTUWWEhfLxMVVkZsgRsMAgAEhqIA= Date: Fri, 25 Apr 2014 01:18:51 +0000 Message-ID: References: <34A254A7-000E-4A38-B28E-70DC21F06AAD@senki.org> In-Reply-To: <34A254A7-000E-4A38-B28E-70DC21F06AAD@senki.org> 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.21.120.65] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B701C096417674CA763FC8DBBBA926A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ekMlOG0wmLj9Mz9QZQhJykfT7ZM Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 01:19:00 -0000 Barry, Your observation is correct. We intentionally kept it to a higher level as opposed to going into each of the specific examples in detail, primarily to keep the focus on driving the SFC architecture requirements. If we enumerate service function chains, we will not only have a quite a lengthy draft but will also not demonstrate any new requirements. Your comments well noted and thank you! Surendra. On 4/23/14 6:02 PM, "Barry Greene" wrote: > >I echo Sumandra's observation. This needs another section to provide >context, but the model in the use cases section would work with each >context.=20 > >Additionally, the "use cases" section does not read as "use cases." It is >a very useful tool to use in SFC design in a DC, but not what you usually >see as "use cases." > > >On Apr 24, 2014, at 7:44 AM, Sumandra Majee wrote: > >> I support the adoption but I have following observations. >>=20 >> 1) Datacenter encompasses a lot of application and varied vertical >>market. I would like to see this focus on the enterprise and perhaps the >>cloud DC use cases. Service providers use data center too, but the >>policies are often applied per subscriber and per resource (URL), per >>application. Enterprise datacenter policy may not involve per user >>policy (I think most will not but it does involve a group of users). >>=20 >> There are layers of ADC in the enterprise in the form of, >> L4 distribution =8B=8B=8B=8B ADC 1(with a unicast VIP1) [APP resourc= e] >>=8B=8B=8B=8B=8B ADC2 (VIP2 : APP resource 2). These can be viewed as sam= e >>instance or sometimes NOT. >>=20 >> 2) In the mobile DC when flows are threaded thru a series of VAS, the >>5 tuple remain unchanged. That is not the case in enterprise when there >>is a server to server communication on behalf of a client. The east >>west traffic in cloud DC is quite unruly since the changes are made >>often and new services are created by DevOps every so often. I think >>this is a significantly different from SP datacenter (where scale >>matters but number of unique applications are relatively small) and >>should be covered in detail. >>=20 >> I would rather see the focus on enterprise/cloud (call this >>draft-enterprise-=8A.) and cover the uniqueness of that piece of land tha= n >>a generic DC. >>=20 >> Regards. >>=20 >> Sumandra >>=20 >> From: "Jim Guichard (jguichar)" >> Date: Friday, April 18, 2014 at 3:31 >> To: "sfc@ietf.org" >> Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 >>=20 >> Dear WG: >>=20 >> This message begins a two week call for WG adoption of the document >>http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd >>May 2014.=20 >>=20 >> Please respond to the SFC mailing list with any statements of approval >>or disapproval. >>=20 >> Please note: >> =80 This is not WG Last Call. The document is not final, and the WG is >>expected to modify the document=B9s content until there is WG consensus >>that the content is solid. Therefore, please don=B9t oppose adoption just >>because you want to see changes to its content. >> =80 If you have objections to adoption of the document, please state >>your reasons why, and explain what it would take to address your >>concerns. >> =80 If you have issues with the content, by all means raise those issue= s >>and we can begin a dialog about how best to address them. >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Apr 24 21:10: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 21AD81A0274 for ; Thu, 24 Apr 2014 21:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 Ktn_tuSH7PKN for ; Thu, 24 Apr 2014 21:10:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 434001A01BA for ; Thu, 24 Apr 2014 21:10:48 -0700 (PDT) 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 BDL97487; Fri, 25 Apr 2014 04:10:40 +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; Fri, 25 Apr 2014 05:09:55 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 05:10:38 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.143]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 12:10:30 +0800 From: "Liushucheng (Will)" To: "Surendra Kumar (smkumar)" , "Hongyu Li (Julio)" , Lucy yong , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of SFC use case documents Thread-Index: AQHPW1K8K2mTLR48uE+GohTdExdCc5sX9OdggAVYz0CABBg5gIAAWJDw Date: Fri, 25 Apr 2014 04:10:29 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@dfweml701-chm.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E9F312A@SZXEMA509-MBX.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.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FEBA31ESZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-H3g-SceVFbBFZNFNUWt_wR-Gls Cc: "draft-boucadair-sfc-requirements@tools.ietf.org" , "draft-liu-sfc-use-cases@tools.ietf.org" Subject: Re: [sfc] Progression of SFC use case documents 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, 25 Apr 2014 04:10:55 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FEBA31ESZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I second Lucy and Hongyu: not support the adoption of draft-kumar-sfc-dc-us= e-case. Comments inline. Regards, Will (Shucheng LIU) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Friday, April 25, 2014 8:41 AM To: Hongyu Li (Julio); Lucy yong; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Progression of SFC use case documents Inline. From: "Hongyu Li (Julio)" > Date: Tuesday, April 22, 2014 1:58 AM To: Lucy yong >, "Jim Gui= chard (jguichar)" >, "sfc@iet= f.org" > Subject: Re: [sfc] Progression of SFC use case documents Hi Chairs, I support Lucy's comment. draft-kumar-sfc-dc-use-case has a fancy name, but= not so fancy use cases. Snipped from Chairs' email: SK> Our goal is to capture the use cases in enterprise DCs that highlight t= he challenges in deploying legacy service chaining and bring out the requir= ements for SFC architecture with examples. [Will]: In my opinion the requirements for SFC are general enough that only= one general requirement draft can cover all of them perfectly, and draft-b= oucadair-sfc-requirements-04 did a good work on this. The requirement you'v= e mentioned are not special enough to be put somewhere else. Adopt a small number of WG documents (initially 2) that are applicable to s= pecific environments and that can be worked on independently by members of = the WG that have the necessary expertise for that environment, Both mobile and fixed network may put their Service Functions in a virtual = environment, which is very possibly a datacenter. So, draft-kumar-sfc-dc-u= se-case has a great overlap with other use case drafts including, even thou= gh you want to have "specific environments" and clean cuts between them. SK> In fact I would go a step further and say, the concepts underlying all = of them are the same - the reason all use cases are in this WG. The require= ments on the other hand are indeed different, specifically when contrasted = with Mobile SP. Although NFV is shining some light on SFC through Mobility use cases in rec= ent days, enterprise use cases have existed for a very long time. There are= a lot more enterprise deployments, small & large, than mobile SP. We would= be better served by not ignoring the vast majority of the SFC deployments,= in major enterprise DCs, pretty much everywhere. [Will]: You also agree that the concepts underlying all of them are the sa= me. That's why we believe there is no need for accepting such a so called s= tandalone draft about DC, given that there is already a general one covered= the use case of DC well. and that can work directly with the applicable SDOs on incorporating releva= nt content. There was a question on the mailing list asking what are the SDOs draft-kum= ar-sfc-dc-use-case is corresponding to, but no answer was posted so far. SK> Do you have a suggestion for an SDO for enterprise DC ? Surendra. So, it seems draft-kumar-sfc-dc-use-case doesn't serve your purpose at all. BR, Hongyu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Saturday, April 19, 2014 7:06 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Progression of SFC use case documents Dear Chairs, People including myself did not voice a single document to capture all poss= ible use cases because there is no need to do that. We suggested capturing = all necessary use cases that help driving the architecture and requirement = development. Giving the situation, I support adopting draft-haeffner-sfc-use-case-moblit= y as WG draft. This is because a large portion of SFC use cases are in Mobi= le applications; and the draft describes many unique ways to use SFC. It is= good to have one draft to cover Mobile area. IMO: draft-kumar-sfc-dc-use-cases does not depict unique SFC cases from a g= eneral SFC case except the SFC applications location is in data centers. Th= us these cases can be easily merged into the general use case draft. So we = have another use case draft for the rest. Regards, Lucy Dear WG: There has been much discussion both on the list and during our face-to-face= meetings about how best to progress use case documents within the WG. Ther= e are clearly arguments for both of the following approaches: 1. A single document that captures all of the possible use cases. 2. A small number of targeted documents that are focused on a particular= subset of the overall problem space (such as broadband, mobility, and data= center). But, we can't choose both. In considering these approaches, the chairs reco= gnize that there are benefits to having a single document, but do not belie= ve having just one document is workable in this case. Nor is there consensu= s for having a single document. Therefore, we will pursue the following ap= proach going forward: 1. Adopt a small number of WG documents (initially 2) that are applicabl= e to specific environments and that can be worked on independently by membe= rs of the WG that have the necessary expertise for that environment, and th= at can work directly with the applicable SDOs on incorporating relevant con= tent. 2. Continue to leave open the possibility of adopting a high-level use c= ase document that serves as a "catch all" for use cases that do not merit t= heir own document or are not captured in the content of more focused use ca= se documents. However, before taking on such a document, the WG will need t= o understand in more detail what the content would be and that the content = justifies having such a document. Such a document should not duplicate mate= rial that is covered in other documents. To facilitate the above direction the chairs will take the following steps: 1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and draf= t-kumar-sfc-dc-use-cases as WG documents. 2. Encourage the authors to continue to work on refinement of draft-liu-= sfc-use-cases. The authors of that document should update their draft to re= move any duplication of material covered in other documents as well as iden= tify content that is not covered elsewhere. We hope that this approach will allow the WG to move forward and also provi= de enough flexibility to allow use cases to evolve independently, with dire= ct interaction with the appropriate SDOs. Thanks, Jim & Thomas --_000_C9B5F12337F6F841B35C404CF0554ACB5FEBA31ESZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I second Lucy and Hongyu:= not support the adoption of draft-kumar-= sfc-dc-use-case.

Comments inline.

 <= /p>

Regards,

Will (Shucheng LIU)

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkumar)
Sent: Friday, April 25, 2014 8:41 AM
To: Hongyu Li (Julio); Lucy yong; Jim Guichard (jguichar); sfc@ietf.= org
Subject: Re: [sfc] Progression of SFC use case documents<= /span>

 

Inline.

 

From: "Hongyu Li (Julio)" <hongyu.li@huawei.com>
Date: Tuesday, April 22, 2014 1:58 AM
To: Lucy yong <lucy.yong@= huawei.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sf= c@ietf.org>
Subject: Re: [sfc] Progression of SFC use case documents<= /span>

 

Hi Chairs,

 

I support Lucy’s co= mment. draft-kumar-sfc-dc-use-case has a fancy name, but not so fancy use c= ases. Snipped from Chairs’ email:<= o:p>

SK> Our goal is to capture = the use cases in enterprise DCs that highlight the challenges in deploying = legacy service chaining and bring out the requirements for SFC architecture with examples.<= /span>

[Will]: In my opinion the= requirements for SFC are general enough that only one general requirement = draft can cover all of them perfectly, and draft-boucadair-sfc-requirements= -04 did a good work on this. The requirement you’ve mentioned are not sp= ecial enough to be put somewhere else.

 <= /p>

Adopt a small number of WG = documents (initially 2) that are applicable to specific environments and th= at can be worked on independently by members of the WG that have the necessary expertise for that environment,

Both mobile and fixed net= work may put their Service Functions in a virtual environment, which is ver= y possibly  a datacenter. So, draft-kumar-sfc-dc-use-case has a great overlap with other use case drafts including, even though you = want to have “specific environments” and clean cuts between the= m.

SK> In fact I would go a st= ep further and say, the concepts underlying all of them are the same - the = reason all use cases are in this WG. The requirements on the other hand are indeed different, specifically when contrasted with Mobile = SP. 

Although NFV is shining some l= ight on SFC through Mobility use cases in recent days, enterprise use cases= have existed for a very long time. There are a lot more enterprise deployments, small & large, than mobile SP. We would be bet= ter served by not ignoring the vast majority of the SFC deployments, in maj= or enterprise DCs, pretty much everywhere.

[Will]: You also agree tha= t the  concepts underlying all of them are the same. That’s why = we believe there is no need for accepting such a so called standalone draft about DC, given that there is already a general one covered the use = case of DC well.

and that can work directly with the applicable SDOs on incorporating rel= evant content.

There was a question on t= he mailing list asking what are the SDOs draft-kumar-sfc-dc-use-case is cor= responding to, but no answer was posted so far.

SK> Do you have a suggestio= n for an SDO for enterprise DC ?<= /span>

 

Surendra.

 

So, it seems draft-kumar-= sfc-dc-use-case doesn’t serve your purpose at all.

 

BR,

Hongyu

 

From: sfc [mailto:sfc-bou= nces@ietf.org] On Behalf Of Lucy yong
Sent: Saturday, April 19, 2014 7:06 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] Progression of SFC use case documents

 =

Dear Chairs,

 

People including my= self did not voice a single document to capture all possible use cases beca= use there is no need to do that. We suggested capturing all necessary use cases that help driving the architecture and requirement= development.

 

Giving the situatio= n, I support adopting draft-haeffner-sfc-use-case-moblity as WG draft. This= is because a large portion of SFC use cases are in Mobile applications; and the draft describes many unique ways to use SFC. It is g= ood to have one draft to cover Mobile area.

 

IMO: draft-kumar-sf= c-dc-use-cases does not depict unique SFC cases from a general SFC case exc= ept the SFC applications location is in data centers. Thus these cases can be easily merged into the general use case draft. So we ha= ve another use case draft for the rest.

 

Regards,=

Lucy=

 =

Dear WG:

 

There has been much discuss= ion both on the list and during our face-to-face meetings about how best to= progress use case documents within the WG. There are clearly arguments for both of the following approaches:

  1. A single document that captures all of the possible use cases.=
  2. A small number of targeted documents that are focused on a par= ticular subset of the overall problem space (such as broadband, mobility, a= nd data center).

But, we can’t choose = both. In considering these approaches, the chairs recognize that there are = benefits to having a single document, but do not believe having just one document is workable in this case. Nor is there consensus for hav= ing a single document.  Therefore, we will pursue the following approa= ch going forward:

  1. Adopt a small number of WG documents (initially 2) that are ap= plicable to specific environments and that can be worked on independently b= y members of the WG that have the necessary expertise for that environment, and that can work directly with the applicable SDOs = on incorporating relevant content.
  2. Continue to leave open the possibility of adopting a high-leve= l use case document that serves as a “catch all” for use cases = that do not merit their own document or are not captured in the content of more focused use case documents. However, before taking on such a docum= ent, the WG will need to understand in more detail what the content would b= e and that the content justifies having such a document. Such a document sh= ould not duplicate material that is covered in other documents. 

To facilitate the above dir= ection the chairs will take the following steps:

  1. Call for the adoption of draft-haeffner-sfc-use-case-moblity a= nd draft-kumar-sfc-dc-use-cases as WG documents.
  2. Encourage the authors to continue to work on refinement of dra= ft-liu-sfc-use-cases. The authors of that document should update their draf= t to remove any duplication of material covered in other documents as well as identify content that is not covered elsewhere. =

We hope that this approach = will allow the WG to move forward and also provide enough flexibility to al= low use cases to evolve independently, with direct interaction with the appropriate SDOs.

 

Thanks,

 

Jim & Thomas

--_000_C9B5F12337F6F841B35C404CF0554ACB5FEBA31ESZXEMA509MBSchi_-- From nobody Thu Apr 24 23:00: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 C88B01A0323 for ; Thu, 24 Apr 2014 23:00:25 -0700 (PDT) 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 U-vnNe00Pwx8 for ; Thu, 24 Apr 2014 23:00:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4741D1A041D for ; Thu, 24 Apr 2014 23:00:03 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id E1D3C190878; Fri, 25 Apr 2014 07:59:55 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 9642F180042; Fri, 25 Apr 2014 07:59:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 25 Apr 2014 07:59:52 +0200 From: To: "Jani, Nrupal" , "sfc@ietf.org" Date: Fri, 25 Apr 2014 07:59:51 +0200 Thread-Topic: thought for the possible new requirement Thread-Index: Ac9f2FK/kM9cxMQFTOi94coBmqw9VAAcp4WA Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B45191@PUEXCB1B.nanterre.francetelecom.fr> References: <096DE3A060628644893976A610FDE6F26C29EFCF@ORSMSX115.amr.corp.intel.com> In-Reply-To: <096DE3A060628644893976A610FDE6F26C29EFCF@ORSMSX115.amr.corp.intel.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_94C682931C08B048B7A8645303FDC9F36F58B45191PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.230321 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0YypEmmRfoQy1NLiSnDzr2rVExI Subject: Re: [sfc] thought for the possible new requirement 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, 25 Apr 2014 06:00:26 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F58B45191PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Nrupal, A requirement draft I'm aware of included in a previous version this requir= ement (http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#page-= 8): DISC_REQ#4: The solution SHOULD allow the dynamic discovery of additional information characterizing a Service Function, including: * The capabilities of the Service Function. * The capacity of the Service Function. For example, this information can refer to the maximum number of binding entries that can be supported by a NAT function, the maximum number of IP-in-IP tunnels that can be established, the maximum link capacity, etc. Does this text reflect what you have in mind? Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jani, Nrupal Envoy=E9 : jeudi 24 avril 2014 18:15 =C0 : sfc@ietf.org Objet : [sfc] thought for the possible new requirement Hi there, First of all, I want to thank this WG for putting out great RFCs capturing = various requirements and usecases. I see possibility of one additional requirement, which is either not captur= ed or is there but not explicit, may be just the interpretation problem!! As we know SFC domain could contain multi-vendor SFs hosted in various form= factors, e.g. Virtual Machine, Linux Container, Bare-Metal or Physical App= liance. Additionally traffic passes through the combination of SW & HW Swi= tches, where there could be a packet loss due to various reasons. While RFCs are calling out OAM, diagnostic and elasticity related requireme= nts and SLA related usacases, I see a need to provide real-time effective B= W for given SFC. It can be useful for runtime provisioning of SFC instance= s (i.e. elasticity) of a given SFC, or to migrate SF instances to an approp= riate SF node!! For the initial thought, SF Node could be a better entity to provide real-t= ime information of each SFC chains, given that it is the anchor point in SF= C related traffic. Or could be some other ways!! Furthermore not related to requirement, but like TPCC perf. matrix from var= ious server platform vendors, having upfront perf. matrix from appliance ve= ndor for a given form factor (i.e. Virtual Machine, Linux Container, Bare-M= etal or Physical Appliance) could help admin initial provisioning of a give= n SFC. Thanks, Nrupal. --_000_94C682931C08B048B7A8645303FDC9F36F58B45191PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Nrupal,<= /o:p>

 

A requirement draft I’m aware of included in a previous versio= n this requirement (http://tools.ietf.org/html/draft-boucadair-sfc-r= equirements-03#page-8):

&n= bsp;

=A0=A0 DISC_REQ#4:=A0 The solution SHOULD allow t= he dynamic discovery of

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 additional information characterizing a Service<= /o:p>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Function= , including:

 

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *=A0 The capabilities of the Ser= vice Function.

 

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *=A0 The capacity of the Serv= ice Function.=A0 For example,

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this information can refer to the maxi= mum number of

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 binding entries that can be supported by a NAT

=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= function, the maximum number of IP-in-IP tunnels that

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 can be establis= hed, the maximum link capacity, etc.

Does this text reflect wha= t you have in mind?

 

Cheers,

Med

 =

 

<= p class=3DMsoNormal>De : sfc [mailto:sfc-bounces@ietf.org] D= e la part de Jani, Nrupal
Envoy=E9 : jeudi 24 a= vril 2014 18:15
=C0 : sfc@ietf.org
Objet : [s= fc] thought for the possible new requirement

 

Hi there,=

 

First of all, I want to thank this WG for putting out great RFCs capturi= ng various requirements and usecases. 

 

I see possibility of one add= itional requirement, which is either not captured or is there but not expli= cit, may be just the interpretation problem!!

 

As we know SFC domain could= contain multi-vendor SFs hosted in various form factors, e.g. Virtual Mach= ine, Linux Container, Bare-Metal or Physical Appliance.  Additionally = traffic passes through the combination of SW & HW Switches, where there= could be a packet loss due to various reasons.

 

While RFCs are calling ou= t OAM, diagnostic and elasticity related requirements and SLA related usaca= ses, I see a need to provide real-time effective BW for given SFC.  It= can be useful for runtime provisioning of SFC instances (i.e. elasticity) = of a given SFC, or to migrate SF instances to an appropriate SF node!!=

 

Fo= r the initial thought, SF Node could be a better entity to provide real-tim= e information of each SFC chains, given that it is the anchor point in SFC = related traffic.   Or could be some other ways!!

 

Furthermore no= t related to requirement, but like TPCC perf. matrix from various server pl= atform vendors, having upfront perf. matrix from appliance vendor for a giv= en form factor (i.e. Virtual Machine, Linux Container, Bare-Metal or Physic= al Appliance) could help admin initial provisioning of a given SFC.

 

Thank= s,

 

Nrupal.

 

 

 <= /p>

= --_000_94C682931C08B048B7A8645303FDC9F36F58B45191PUEXCB1Bnante_-- From nobody Thu Apr 24 23:12: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 AAAF61A03BC for ; Thu, 24 Apr 2014 23:11:39 -0700 (PDT) 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 O_vwGTy14Bto for ; Thu, 24 Apr 2014 23:11:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3333B1A02F9 for ; Thu, 24 Apr 2014 23:11:11 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 328C62643AF; Fri, 25 Apr 2014 08:11:04 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DA09E27C066; Fri, 25 Apr 2014 08:11:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 25 Apr 2014 08:11:03 +0200 From: To: Linda Dunbar , "sfc@ietf.org" Date: Fri, 25 Apr 2014 08:11:02 +0200 Thread-Topic: Suggestion to draft-boucadair-sfc-requirements-04 Thread-Index: Ac9gA8EBGGbFmEDAT+ugVpKoBP5k5wAR9bBg Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B45193@PUEXCB1B.nanterre.francetelecom.fr> References: <4A95BA014132FF49AE685FAB4B9F17F645CFD182@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CFD182@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_94C682931C08B048B7A8645303FDC9F36F58B45193PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.130918 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oHb-shXQlcqWtllTxCbBOpYz8gM Subject: Re: [sfc] Suggestion to draft-boucadair-sfc-requirements-04 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, 25 Apr 2014 06:11:39 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F58B45193PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for the proposal. It sounds good to me. I have no problem to re-organize the text accordingly, but before doing tha= t I'd prefer to see first whether the group is interested to work on this d= ocument. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Linda Dunbar Envoy=E9 : jeudi 24 avril 2014 23:26 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : [sfc] Suggestion to draft-boucadair-sfc-requirements-04 Mohamed, et al, The draft listed 30 plus requirements under one category "Detailed Requirem= ent List". I think that requirement list should be grouped by category. Usi= ng RFC 5654 as a good reference, Service Chain should at least have the fol= lowing category: - Service Chain General Requirement - Data Plane requirement o Encapsulation requirement o Service Function identification requirement o etc - Control Plane requirement - Protection & Restoration requirement - OAM requirement Yours, Linda --_000_94C682931C08B048B7A8645303FDC9F36F58B45193PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda= ,

 

Thank you for the proposal. It sounds good to me.

 

I have no problem to re-organize the text accordingly, but befor= e doing that I’d prefer to see first whether the group is interested = to work on this document.

&nb= sp;

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Linda Dunbar
= Envoy=E9 : jeudi 24 avril 2014 23:26
=C0 : BOUCA= DAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : [sfc] Suggestion = to draft-boucadair-sfc-requirements-04

 

Mohamed, et al,=

 

The draft listed 30 plus requirements under one category “Detaile= d Requirement List”. I think that requirement list should be grouped = by category. Using RFC 5654 as a good reference, Service Chain should at le= ast have the following category:

&n= bsp;

-=      =      Service Chain General Requ= irement

-   &nb= sp;      Data Plane requir= ement

o   Encapsulation requirement

o  = Service Function identification requirement=

o   etc

-    = ;      Control Plane requi= rement

-   &nbs= p;      Protection & R= estoration requirement

- &= nbsp;        OAM= requirement

 

Yours,

 

Linda

= --_000_94C682931C08B048B7A8645303FDC9F36F58B45193PUEXCB1Bnante_-- From nobody Thu Apr 24 23:23: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 D0A751A0424 for ; Thu, 24 Apr 2014 23:23:05 -0700 (PDT) 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 JRHyMajE8nDF for ; Thu, 24 Apr 2014 23:23:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5091A035C for ; Thu, 24 Apr 2014 23:23:03 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 596262AC760 for ; Fri, 25 Apr 2014 08:22:56 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 3D22D18004F for ; Fri, 25 Apr 2014 08:22:56 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.110]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 25 Apr 2014 08:22:51 +0200 From: To: BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" Thread-Topic: IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QAx+dPQ Date: Fri, 25 Apr 2014 06:22:50 +0000 Message-ID: <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_5af784bad2f34684ba301e4bcb8f9c3bOPEXCLILH01corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.230321 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qJ0FzUw988Eca7gGie9pJO_r0Xc Subject: Re: [sfc] IPR related to draft-ietf-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, 25 Apr 2014 06:23:06 -0000 --_000_5af784bad2f34684ba301e4bcb8f9c3bOPEXCLILH01corporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG, I'd like to second Med's comment: an IPR disclosure is a bit incongruous fo= r a document that is supposed to document a problem statement and only a pr= oblem statement. From this perspective, the current Section 3 is no less mi= splaced. Cheers, Christian. De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I'm surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3). I'm re-iterating my comment to remove section 3 from the PS draft as it see= ms this is the only part that is close to the solution part than the proble= m discussion. Cheers, Med ___________________________________________________________________________= ______________________________________________ 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_5af784bad2f34684ba301e4bcb8f9c3bOPEXCLILH01corporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

WG,

 

I’d like to second Med’s comment= : an IPR disclosure is a bit incongruous for a document that is supposed to= document a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplaced.

 

Cheers,

 

Christian.

 

De = : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0 : sfc@ietf.org
Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,

 

When checking the tracker, I = found there is an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_= search&id=3Ddraft-ietf-sfc-problem-statement

 

I’m surprised to see su= ch disclosure for a document that is supposed to describe only problems (ex= cept section 3).

 

I’m re-iterating my com= ment to remove section 3 from the PS draft as it seems this is the only par= t that is close to the solution part than the problem discussion.

 

Cheers,

Med

______________________________________________________________________=
___________________________________________________

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_5af784bad2f34684ba301e4bcb8f9c3bOPEXCLILH01corporateadr_-- From nobody Thu Apr 24 23:52: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 3B7E61A0412 for ; Thu, 24 Apr 2014 23:52:35 -0700 (PDT) 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 FgsDaJbcccz6 for ; Thu, 24 Apr 2014 23:52:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 300941A007F for ; Thu, 24 Apr 2014 23:52:33 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7571C2AC326; Fri, 25 Apr 2014 08:52:26 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 528B138408C; Fri, 25 Apr 2014 08:52:26 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 25 Apr 2014 08:52:26 +0200 From: To: Lucy yong , Ron Parker , "Jim Guichard (jguichar)" , Sharon Date: Fri, 25 Apr 2014 08:52:24 +0200 Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt Thread-Index: AQHPWaiTRUhA6Ab40kaZyfxW4WYVnJsUw7DQgAGCMACAAAPMAIAAAYSA//+NsZCACnkxMIAAk4VQgAEDZHA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B451A7@PUEXCB1B.nanterre.francetelecom.fr> References: <20140416191749.26793.70486.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D45371259@dfweml701-chm.china.huawei.com> <0F99B41E-9CE3-49F1-8D2D-9994D32F0F81@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D453714BA@dfweml701-chm.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F58B44EEB@PUEXCB1B.nanterre.francetelecom.fr> <2691CE0099834E4A9C5044EEC662BB9D45373045@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45373045@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: 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.4.24.50019 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fQd-TNa180GsE_ftPRTK5mApNRI Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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: Fri, 25 Apr 2014 06:52:35 -0000 Hi Lucy, This requirement draft uses the term "context" because this is the term use= d in the sfc charter: " - communicates context information between nodes that implement=20 service functions and Service Function Chains. " Cheers, Med >-----Message d'origine----- >De=A0: Lucy yong [mailto:lucy.yong@huawei.com] >Envoy=E9=A0: jeudi 24 avril 2014 17:36 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Ron Parker; Jim Guichard (jguichar); Sh= aron >Cc=A0: sfc@ietf.org >Objet=A0: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >Hi Mohamed, > >Thank you for the explanation. If the metadata means the association of a >context with the data packets, it is better to explicitly mention that >"metadata" is often term used to such context in the requirement draft as >well. This will make the requirement document better aligns with other PS >and other documents. In standard, we often spend a lot of time to make >censuses on one term and/or one description. > >In PS doc, it defines and explains the data plane metadata, which is one >way to convey the association of a context with the data packets, there ar= e >other ways to convey such association. > >Current description in REQ#22 is not clear to me. Profiles/policies are >described as some configuration at local Service Function. It is hard to >draw any relationship to the association of a context with the data >packets. Since the association of a context with data packets or metadata >is one of main characteristics that SFC will supports, it is very importan= t >for req. doc to depict the requirements on the metadata. > >Sharon's case expresses a requirement on data plane metadata. They are >others, e.g. the solution MUST provide the association between the metadat= a >and its associated data packets in real time. I agree that we should not >state such requirement in PS doc. > >SFC needs a requirement doc. for sure. IMO: setting a pre-condition for >continually working on a doc. is not proper. It is chair's responsibility >to determine when to adopt; editor's responsibility to capture the right >stuff in a doc.. > >Thanks, >Lucy > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Thursday, April 24, 2014 1:12 AM >To: Lucy yong; Ron Parker; Jim Guichard (jguichar); Sharon >Cc: sfc@ietf.org >Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > >Dear Lucy, > >A requirement draft I'm aware of (https://tools.ietf.org/html/draft- >boucadair-sfc-requirements-04) includes one single item covering this >point: > > REQ#22: The solution MUST allow for the association of a context > with the data packets. In particular: > > A. The solution MUST support the ability to invoke > differentiated sets of policies for a Service Function > (such sets of policies are called Profiles). A profile > denotes a set of policies configured to a local Service > Function (e.g., content-filter-child, content-filter- > adult). > > a. Few profiles should be assumed per Service Function > to accommodate the need for scalable solutions. > > b. A finer granularity of profiles may be configured > directly to each Service Function; there is indeed > no need to overload the design of Service Function > Chains with policies of low-level granularity. > >Additional requirements can be added to capture and record the wg inputs. = I >would prefer to see first the document adopted as WG item before going tha= t >path. > >Back to the point mentioned by Sharon, I do think this is worth to be >considered but not in the problem statement document. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Lucy yong Envoy=E9= =A0: >>jeudi 17 avril 2014 16:06 =C0=A0: Ron Parker; Jim Guichard (jguichar); >>Sharon Cc=A0: sfc@ietf.org Objet=A0: Re: [sfc] I-D Action: >>draft-ietf-sfc-problem-statement-04.txt >> >>I agree that Sharon's use case is very important. >> >>This metadata feature should be captured in the SFC requirement >>document. I am surprised in seeing no metadata word mentioned in the >requirement doc. >>yet. >> >>Lucy >> >>-----Original Message----- >>From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>Sent: Thursday, April 17, 2014 8:55 AM >>To: Jim Guichard (jguichar); Sharon; Lucy yong >>Cc: sfc@ietf.org >>Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >> >>I think Sharon's use case is very important. But, so long as the >>interpretation of metadata is not prescriptive in the problem >>statement, wouldn't this be more appropriate for the use cases document? >> >> Ron >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>(jguichar) >>Sent: Thursday, April 17, 2014 9:49 AM >>To: Sharon; Lucy yong >>Cc: sfc@ietf.org >>Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >> >>Hi Sharon, >> >>I would like to just clarify that I understand your second point. I >>believe you are saying that you would like the data plane metadata to >>carry pointers (rather than the full metadata structure) that may be >>used for key access into a more detailed data structure within the SF >itself correct? >> >>On 4/17/14, 9:35 AM, "Sharon" wrote: >> >>>I agree. Text shapes up nicely. >>>Also re-entrant re-classify recursion spelled out for dynamic forks. >>>We are starting to see functions designed with programability in mind >>>that need it. >>> >>>Would like to see the option of metadata as mappable (eid) key at >>>least mentioned. >>>While it does require some state savings per flow (sfc is very much a >>>flow thing ..), It helps address the different fields that come up, >>>the per packet overhead, out of band complexity-consistency.. reduces >>>the problem to mapping, something we have to solve anyway in many of >>>the sfc use cases. >>> >>>--szb >>> >>>> On Apr 16, 2014, at 14:30, Lucy yong wrote: >>>> >>>> I like the new text about dataplane metadata in section 3.4. >>>> >>>> Cheers, >>>> Lucy >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>internet-drafts@ietf.org >>>> Sent: Wednesday, April 16, 2014 2:18 PM >>>> To: i-d-announce@ietf.org >>>> Cc: sfc@ietf.org >>>> Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>directories. >>>> This draft is a work item of the Service Function Chaining Working >>>>Group of the IETF. >>>> >>>> Title : Service Function Chaining Problem Statement >>>> Authors : Paul Quinn >>>> Thomas Nadeau >>>> Filename : draft-ietf-sfc-problem-statement-04.txt >>>> Pages : 18 >>>> Date : 2014-04-16 >>>> >>>> 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 instances 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-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-04 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 nobody Fri Apr 25 02:34: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 8CBEF1A0359 for ; Fri, 25 Apr 2014 02:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 EE9H_GfPBHks for ; Fri, 25 Apr 2014 02:34:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0771A038D for ; Fri, 25 Apr 2014 02:34:29 -0700 (PDT) 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 BDM22059; Fri, 25 Apr 2014 09:34:22 +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, 25 Apr 2014 10:33:20 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 10:34:19 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.24]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 17:34:10 +0800 From: Weixinpeng To: "Haeffner, Walter, Vodafone DE" , "sfc@ietf.org" , "jguichar@cisco.com" Thread-Topic: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Thread-Index: AQHPW1W5zdi3JeuUaEqhVtKwLHjnVpsgKLoQgABcDJCAAYiFwA== Date: Fri, 25 Apr 2014 09:34:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/related; boundary="_004_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/08ekbR400N50flekMkWMuqY8uJA Cc: "Xiongchunshan \(Sam\)" , "Luwei \(Wei\)" , "Zhouhan \(Joe\)" , "Zhulei \(MBB Research\)" Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 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, 25 Apr 2014 09:34:35 -0000 --_004_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_ Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_" --_000_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Walter, Thanks for your answer. And there are some more comments. I think the following figure is your main solution architecture, am I right= ? If so, I have some questions: (1) What is the difference with the 3GPP classifier and SFC classifier ? In= my view, I think these two logic function can be integrated each other, i.= e. TDF act as these two functions. In this architecture, which node generate the service chain for certain app= lication? (2) As it's known, the service chain is generated by the user profile, and = 3Gpp related information(i.e. RAT type , RAT load). These information (RAT type, RAT load,) is the control plane metadata in yo= ur draft, am I right? Do you mean that IETF SFC domain obtain these information (user profile, RA= T type, RAT load.) via metadata to generate the service chain? As my understanding the branching rule you mentioned has the same mean with= match rule, e.g. 5-tuple, that used to specify which traffic will go throu= gh the SFC graph. Right? [cid:image002.png@01CF6080.E57D7AC0] Best Regards, Xinpeng From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] Sent: Thursday, April 24, 2014 6:37 PM To: Weixinpeng; sfc@ietf.org; jguichar@cisco.com Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Research) Subject: AW: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Hi Xipeng, Thanks for supporting our draft. We are currently working on the next editi= on which takes care of all the WG inputs. Wrt section 6.1we had the complete product creation cycle in mind: 1.) Marketing defines a product. 2.) Product (assume a mobile access product) is typically specified by p= arameters like QoS for traffic classes, BW limits, volume limits, charging,= etc. 3.) Marketing asks Product Engineering to specify input to Network/Servi= ce Engineering 4.) Network/Service Engineering maps this into network configs. 5.) Operations finally implements and maintain this config. So you are right. The "dream environment" for an operator would be a stack = with increased abstraction towards the business-oriented layers. Idea is to= think about an abstract SFC graph with branching rules specified on the "p= roduct requirements level" (metadata) and created by Product Engineering in= some fancy tool box. This may be automatically translated into underlay/tu= nnel configs. This fits pretty much with the WG idea of a new abstracted forwarding mecha= nism based on "Base Header" content already proposed in some early drafts. Branching rules are driven by static or time/state dependent metadata conte= xt. You could make the set of metadata bigger and bigger, but the question = is, what is the minimal set and how we may transfer and manage these metada= ta to come to a feasible and useful SFC environment the operators may (step= wise) introduce. We have to think about it. But, SFC cannot and should not = try to solve all the problems on earth. Abstraction is also not a new idea. Have for example a closer look to Brent= Salisbury's recent open source work on Openstack, OVSDB within Opendayligh= t. This may reflect what could be done within a complete SFC framework. For sure and explicitly stated, not all of this is subject of the SFC WG. B= ut an operator is not only asking for a protocol. He asks for a complete so= lution. What is your opinion? Kind regards, Walter Von: Weixinpeng [mailto:weixinpeng@huawei.com] Gesendet: Donnerstag, 24. April 2014 06:05 An: Haeffner, Walter, Vodafone DE; sfc@ietf.org; jguic= har@cisco.com Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Research) Betreff: RE: Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Hi, Support the document. But I still have some questions: 1. In section 6.1, it states that "The creation of service chains should be embedded in the business and operation support layers of the company and on an abstract functional level..." so what "the business an= d operation support layers" mean here, it's the OSS/BSS or other entities in 3GPP network? 2. As my understanding, the requirement from operator is that the operator = generates an abstract functional level service chain, and sends it to the controller in SFC framework to form a service function chain instance, = the chain compiler and mediation device in figure 10 are a functional part = of controller, am I right? Thanks, Xinpeng From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, April 19, 2014 6:30 AM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May = 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Walter,

Thanks for your answer. And the= re are some more comments.

 

I think the following figure is= your main solution architecture, am I right? If so, I have some questions:=

(1) What is the difference with= the 3GPP classifier and SFC classifier ? In my view, I think these two log= ic function can be integrated each other, i.e. TDF act as these two functio= ns.

In this architecture, which nod= e generate the service chain for certain application?

(2) As it’s known, the se= rvice chain is generated by the user profile, and 3Gpp related information(= i.e. RAT type , RAT load).

These information (RAT type, RA= T load,) is the control plane metadata in your draft, am I right?

 

Do you mean that IETF SFC domai= n obtain these information (user profile, RAT type, RAT load.) via metadata= to generate the service chain?   

 

As my understanding the branchi= ng rule you mentioned has the same mean with match rule, e.g. 5-tuple, that= used to specify which traffic will go through the SFC graph. Right?

 

3D"cid:image002.png@01CF6080.E57D7AC0"

 = ;

 = ;

Best Regards,=

Xinpeng

 = ;

From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner= @vodafone.com]
Sent: Thursday, April 24, 2014 6:37 PM
To: Weixinpeng; sfc@ietf.org; jguichar@cisco.com
Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Res= earch)
Subject: AW: Call for adoption of draft-haeffner-sfc-use-case-mobili= ty-01

 

Hi Xipeng,=

 = ;

Thanks for= supporting our draft. We are currently working on the next edition which t= akes care of all the WG inputs.

 = ;

Wrt sectio= n 6.1we had the complete product creation cycle in mind:<= /p>

 = ;

1.)    Ma= rketing defines a product.

2.)    Pr= oduct (assume a mobile access product) is typically specified by parameters= like QoS for traffic classes, BW limits, volume limits, charging, etc.

3.)    Ma= rketing asks Product Engineering to specify input to Network/Service Engine= ering

4.)    Ne= twork/Service Engineering maps this into network configs.=

5.)    Op= erations finally implements and maintain this config.

 = ;

So you are= right. The “dream environment” for an operator would be a stac= k with increased abstraction towards the business-oriented layers. Idea is to think about an abstract SFC graph with branching rules specified on = the “product requirements level” (metadata) and created by Prod= uct Engineering in some fancy tool box. This may be automatically translate= d into underlay/tunnel configs.

 = ;

This fits = pretty much with the WG idea of a new abstracted forwarding mechanism based= on “Base Header” content already proposed in some early drafts= .

 = ;

Branching = rules are driven by static or time/state dependent metadata context. You co= uld make the set of metadata bigger and bigger, but the question is, what is the minimal set and how we may transfer and manage these metad= ata to come to a feasible and useful SFC environment the operators may (ste= pwise) introduce. We have to think about it. But, SFC cannot and should not= try to solve all the problems on earth.

 = ;

Abstractio= n is also not a new idea. Have for example a closer look to Brent Salisbury= ’s recent open source work on Openstack, OVSDB within Opendaylight. This may reflect what could be done within a complete SFC framework.<= /o:p>

 = ;

For sure a= nd explicitly stated, not all of this is subject of the SFC WG. But an oper= ator is not only asking for a protocol. He asks for a complete solution.

 = ;

What is yo= ur opinion?

 = ;

Kind regar= ds,

 = ;

Walter

 = ;

 = ;

Von: Weixinpeng [mailto:= weixinpeng@huawei.com]
Gesendet: Donnerstag, 24. April 20= 14 06:05
An: Haeffner, Walter, Vodafone DE; sfc@ietf.org; jguichar@cisco.com
Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Res= earch)
Betreff: RE: Call for adoption of draft-haeffner-sfc-use-case-mobili= ty-01

 

Hi,

Support th= e document. But I still have some questions:

 = ;

1. In section 6.1, it states that “The creation of service chains should

&= nbsp;  be embedded in the business and operation support layers of the=

   company and on an = abstract functional level…” so what “the business and operation support layers” mean here, it̵= 7;s

the OSS/BS= S or other entities in 3GPP network?

2. As my u= nderstanding, the requirement from operator is that the operator generates = an abstract functional level service chain, and sends it to

the contro= ller in SFC framework to form a service function chain instance, the chain = compiler and mediation device in figure 10 are a functional part of controller, am I right?

 = ;

Thanks,

Xinpeng

 = ;

 = ;

From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, April 19, 2014 6:30 AM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobi= lity-01

 

Dear WG:

 <= /o:p>

This message= begins a two week call for WG adoption of the document http://www= .ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014. 

 <= /o:p>

Please respo= nd to the SFC mailing list with any statements of approval or disapproval.<= o:p>

 <= /o:p>

Please note:=

  1. This is not WG Last Call. The document is not f= inal, and the WG is expected to modify the document’s content until t= here is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its co= ntent.
  2. If you have objections to adoption of the docum= ent, please state your reasons why, and explain what it would take to addre= ss your concerns.
  3. If you have issues with the content, by all mea= ns raise those issues and we can begin a dialog about how best to address t= hem. 
--_000_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_-- --_004_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=69715; creation-date="Fri, 25 Apr 2014 09:34:09 GMT"; modification-date="Fri, 25 Apr 2014 09:34:09 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAu8AAAE5CAYAAAAgDM7+AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAP+QSURBVHhe 7J0FoFXF9sbX7YBLd5coKioKKFgg2B3Pbp/d3fHsfMazE7v/ditioAgISIt0STe34//95pyNxytw L5cb59wz45t3LufsPXv2mrVnf7PmW2sllKhYGaWgsMgmTPvTlixfY4mJCWUd7n/3EvAS8BLwEvAS 8BKoZgnwNk/QK7pti4bWuW1TS+QfvngJeAnUOgkklAe8f/rjJHvkje9t+eocy8krcELwU0Kt0wV/ Q14CXgJeAl4CMSoBrHCA9Yz0VOvQsqHdcvb+tmX7JjF6N77bXgJeAhuTQLnA+x3PfmEvfTLC2jTL sq3aN3fAvbhsg72XvJeAl4CXgJeAl4CXQDVIICkp0dbm5NmE6YusqCTB7r7gQBu4y1bVcGV/CS8B L4HqlkC5wPu9g76yx9/+0fbZeQt7+MqjLCU50YqLiqq7r/56XgJeAl4CXgJeAl4C65FAcmqq/TFr gf37tjcsO7/EHrjkEOvXs6uXlZeAl0AtlEC5wfsT7wy1vXt3sUeuOtKSxHsvFA/eFy8BLwEvAS8B LwEvgZqXQEZmmk2eJvB++1uWW1Bi919ysAfvNT8svgdeAlUigU0C7wN7dbGHrjjcgXecWH3xEvAS 8BLwEvAS8BKoeQnUFXifOH2BnX3nOx681/xw+B54CVSpBKoOvOPlnpQUcn33JX4lUFxstjGKFfqR nBy/8vF3LgeaMnQkUkZ+XvEagwTwuSos9LKIkIAH714dvATiRwKJVXKrYWfWEoH3ksREX+NVBgAt 3ftGi47xOhLHz0gAxsszEQXzSrw+T/6+Q3MFOhMYhXzghPI8Of4YLwEvgVomgcq3vGsyLcnMtKRp 0yztqqssYcWKsgFcLROqv52wBGRxL+rZ0/Juuy2kA6UsZU5PfvzR0m+9NfRbWUDfC7b2SUA6UrjT TpaPjrBTtyFrKvNKnTqWOH26pTOvLFvm9aX2aUP57oh5ZccdQ/NKSopZfr7f4ZXkvOW9fOrjj/IS qA0SqBrwXq+eJf36q9Xp08esIBQX3pf4lEDxLrvY2q+/DlFjeMlGlJKsLEt+6y3LPOaY+BSOv2sn gaLevS37m2/MFC3D8vLWLxXAO/PKmDFWp29fs5wcL704lkBhr16Wg86kpZnl5nrw7sF7HD8N/tbj UQJVR5uBMqOXrS/xLQGspRstADYsrr7ErQTK1JFIyUCb8PNK3OrKuhsva17xEvIS8BLwEqjFEqga 8F6LBeZvzUvAS8BLwEvAS8BLwEvAS8BLoKYk4MF7TUneX9dLwEvAS8BLwEvAS8BLwEvAS2ATJeDB +yYKzB/uJeAl4CXgJeAl4CXgJeAl4CVQUxKIPvAOB7pJE7NmzcrHhcYR8oorzK6+2iw9vXLliDNU 06YVi0NOv7gP7qcyCn2hPSp9atCg4q1utZXZ/febPfOM2X77mTVuHHL8ysgwu+kms9NPr3jbsXwm 0W6QKzJGHpVRDjggJOvWrUOtVWbbgY4RccOX2JIAzxrPHc9yw4bln2Pk3GsPP2zWo0fofmlDUZt8 8RLwEvAS8BKIHwlEF3jfYguzl14yGzzYTCEE7bHHzFq23PhoALjOOCNUKzMhFO0qJJ199ZVZ9+4b 7wNAb7fdzHbe+a+XMACYc/fcs3K06fDDQ+0NGWL2/fdmRFo4++wQ4N6UUreu2T33mF1+udkOO5id eKIZ0WCOPz6UTOn8882OPHJTWqw9x6J/H35o9u23ZkEYus29u379QrJu1CgkV2Q9YMCmtwpAQ5cU etOF1ETXGSt0QpE3fIkRCTBuLOj+7//MfvghNM/xPD/9tNk225R9E8xFF11k1qmTGUAeffr3v8s+ zx/hJeAl4CXgJVBrJBA94B2rOWCEsIFjx5q9847Z3nub7bNPSNj8HlixsTgCWolSQpKO1avN1q4N /c5xpTN2cqzCEv7NMs+xRCwIrJYAouAaHM9vM2aYffCB2eLFoWsB0mmb4yJBM6Dv7bfNnnoq9FKl LFxo9tFHZnPn/qUsnE+7kedGXpc+AdLWtwjBcgvYXrPG7JNPzLbc0uzRR/+ywAV9j7TC8R3Xi9yR aN7cTDGSbfbskIX93nvNPv7YbNKk0D0iy+zsv/qMfEr3udaof8SNMK6Aa4W2tG23Df0N4KYwHowd 4xPIIzJCDt8HuoH8Iy3hhDRctSok26VLQzqB7IPC2ESOeaAPLLIixxLQxrn/+59Zu3ahPs2fH1ps LFjwdx3jvMgxD9qkX/TTW2prToNZaAU7XugB48dYn3aa2S23hPSEGsxjzBWRu0BBuFWy0qJbn35q 9ttvIX0I5oANzSPx8izX3Oj6K3sJeAl4CVSLBKIHvPNiYfuYwssK0AyAev/90NYwn1hDKUcdFbJA n3JKKKkL4KhLlxAIHTkyBPwBYLRzySUh6xQWynffNevWzeyII8y+/NJMsejdb1i8AMaffx6y+o8a FVpE0C7WdMAPsaWxdtOvX34x+/lns/POCwG8m282a9EiZKF//fXQd4B3rKRBSDMs3EOHhq7J+Tfc EOofNIpXXw29hLHEDRsWAmjQhiJLEC9/3LhQn0lSE8RO5zrcH30fPtzs0ktD1jja4nr09ayzQpSQ 2283a9XKDBD/wAOh/gEG27QJWd4pQdZCKDWffRbq708/hY7nPmtjYXHH7kNgBUUmACoKoOjxx0Nj hOxHjDB77bXQAopy/fUh+aM/6B+Lq913/0uWgDEWRIwZ4A2wRrnjjtAYjR5t9vzzIT0/+uiQvAOr 7H//G9Lt664LLUA5n2sDwAMdC8A4izHaQ39pg50jgBxj/eaboX5h6UUfoPIEz1ttHM9ovCeed3SM 5+/GG80OO8zsyitD89mUKaGFI/PBcceF9IxnD31i3sFaD0APnk3mAxaDzDnMNzzHL74Y0lF0mPFH Zxl7CtdCP/keHbjrrn/OMdEoM98nLwEvAS8BL4F/SCB6wDsWXwDKoEGhFw0ghBdcwAcFDG23XegG sEKzZYyVm5cZoJOXF9lcFy0yO/TQ0EuRFxvACuDNi46XF3xvACwJpADCnMfxgFJoCQB5ALAyxJoy P9q++4b6QN1119DvnNe2rRnAihcux5MoZOXK0N8kmsEav//+oXa5H6xtAHKAE+CNhQjf03/ahUqB hT/YgWBhElmClzagnJc6L3lezr//HqIWQdvh3pAbFJsnnwwBN66HvB58MLQQ4eVN/+gvwB7gd+yx ofvCqsd1+I37u/vukJwBA1gAL7sstGCpjQX5d+xo9sUXIWCDVZvFCwXQhL5wDAB8yZIQyMY/gAKI D8A6uzXsGN13X2jRhywpLDJpH31ioXTggSFwzTgC3lmAMT4ssLDIMsacy0KM9gHktLF8eUjHAG9b bx0CdQA0xpAxr18/NOYsBKBH9e8fGlN0m379+WfoGKg8gERfqk8CPI/oACWYM/ib55DnFr3YY48Q uGdOYH5TRln3N88iuhFY3hl/5pODDw7pQWBgQEfRERb255xjdsIJZp07h85nPkM3APvXXGN25pmV SzWsPkn6K3kJeAl4CcS1BKIHvPNiA5wAunHGeu+9kIWclw9gE3AfWIahjgBIgiyLAPBZs0LH8zID /HTtGqKCYOEG+PCi46WINR/rO9vV//pXCOhCR6DQ/q23hiz68J4D+gpb1MG1AcFY0aGbBDSY554L Afc//giBIig8vEyxtgLGuQc+WTRgzQW0UQJrN22zsDjkkBAAo5Tm+gd9wbLGPe61VwhMI5fgNxYE vLDZxcDay2KI62HhBaST3AZqDwsZQCbfIzfkHmQpDMA7YG/77UO7D1h4sf5hceZ37q22FfQAGeH8 DAUK+aOHLMAATIwRCzqOQ4cA8Iwfsuc35ITeAMqRE+cDoNAdCscBuAIwjwWW3++8MwS8sZrPmRNa JHE9ABgLCArnYVXlORg/PqRj/M04oHf0m2sz7ix4GXP0PtAjxpc22RVCx154IfRbYJWtbWMZrffD OGBcoAC4gxIs3BhvdlyCRd9JJ4X0ggU6Y4VuBIv4QO8Y1wDQ0z47QAcdFPIXogDUAf8sADFucI1g 94g2KtNPKFrl7vvlJeAl4CVQyyQQPSgMIASIhvoycGAIaFICgA6A4XusiYBnXjqB4x7HdegQogIE nGBeUry4ALc4wWLtxtoE0OJlGLTFSw5AA5AC8AKaghJw57lOAMJ4oQLwAycxFhIBZxmqDsAcUM/x fM+LFToLBWDNTgALFAovcq5J37gu5wS8/tIRRIJ/A/CQEZa6IJV8wL9m0UABPFIuvjgE4s49N/TS B+ghV64HBYMa+A/QPjKlz1hmsQyyGMFqD4jF4gy954kn/gIQteVh4P5YrMybF6KWTJgQ2qFAVgBh 5AU4R0eJ9MECDos544dcGQeOBYjjh4CFE3kBpgKOObINuMzIjcUQBesnizqoV/yNMyI7MuzYBPSa wN+Ca+GvQGSlYGHAWPGMANooF1wQ0jHGnsIig/NZ4LKzQ4n0HaktYxgL98E4vfFGaHHPmLPDw+7N W2+FwDWgGv8FxooxQh8ZZ+afgPcezEnB94EfBvoVzCPMccEY8zyPGRNaGEIFYzeSa/As4yQbzGux ID/fRy8BLwEvAS8BJ4HoAe+8qHihYB0HALPVC1CE34sFG6shgByLJS+qyZP/AtpsLQM0oRBAdRgy JERLwdqOEyxAO7Bu88IEfAGWAeLwiTkeazS8U8B4UABnU6eGrh9Ym+kfVk5epliusZSxQMCSDzjC Mgsopj3OBcRh6WQBAeCDdoJVFhAIjx9gxb0AsihYx7DwQm+ILLTH91yjdPhJrs9vWHUBjNwfbSND rofFDnAI/QWQzvWwvCMTFkUTJ4auj1zpM5Z2ZMFCCUsvlBrkDs2C+w6sf7XlIYJqgNwYEyydp54a Au0sgli8QF8AoCMfLOv9+oXAN/KhMIacj4UT4I3DNaAMYIQ+IV8WcYA25MsiCnoY1nToLVwTmb78 ckhPGBss/lCX0GvOA3Dhb4F+oGOMKeMU6Bg7KvDa6S86z8KV/gEIGXMWrMHCFJ1EXzjfl+qVAPMF fjiM68knhyJGoVcA6cCnh2edZ5Q5B72YOTO0ixj49zDmPPPoJM8pzy66xhgHCzR0jDFmzNFHaDPo IdTD4Fmu7NC61StJfzUvAS8BL4G4lUBCiUpZd3/voK/siXeG2sBeXeyhKw63pMQEKygU8FtfUXMl Aq9JioCQKet2Ai+iTSlsDwMQAZaAC15YFL4D6PCiAxABXgA1vMQAxUHkGV5IWEkBOVinOAdLFu3w Hb9FxmAHmPPyAxATc5mXXRBtBWsqQJxFAxQbwNGFF4ZoFbTB94H4sHrBSQ36TX/hyQOUANX0N+Dv B9vnfAZ94UXMtYN26Cc1KNwD5/Md9xw5bNwzMuD8wPpOO1hlkQvAMYhIEsiE87lvAAL3TZvIFfkH tA3O5Zr0nePob+SYlGNciwSMswGdgXNtxDnoSbIWGZk47AW0pHK0WemHcI/IF3kEtBYuEsTp575x NuY3OOvIAnkBkChY6/F9wHrPeCO/YDGGDtE2C0FANPrIMVhhsYpy7WDHhzb5m8Ud16Ad9J1x5dro IjrGgotxYFz4N9fiWNrj38iaY7gmcuXfjDF6Hey+0FagS5Uu0E1rsFC8/BwWvzyDwW5S6SaYVyTL JAHRTEWgSoj1hUdkfPbA+TRwSg90BiDOcxrMe/ybeYWFWQDYGVfGFH3CWIEeoF/B888zze/oFeeh MwGFC/0I5tdNG7IaP7pQC2inM8gjoPxVUa9CU22Zr8kqunr5m82qk24Tpi2wc+56x3ILSuy+Sw62 /j1FH/XFS8BLoNZJIPrAe7SKGGoNFBvoCMRo9qVcEogJ8F7WnQC+AeiAa/wNShes5fhRAOwBTr5s kgTiErxvkoT8waUlUF3gPTkp0dLTUixBBquoLwkpNnPuQjvpplctJ7/EHrv6CNu5e8eo77bvoJeA l8CmS8CD9/LKDEsWlBnoLIA4X8olgVoB3rGCQ2GBmkDc/tKbVVjK2f3AUbomdxDKNSLRd5AH79E3 JtHeo+oA74kC7Ll5hTZlzmJbuSZXO86wTKPXAp+UlGwLFq+wx975STvjJXbGoTvbNl1aWZH3a4h2 dfb9ixsJJFhJcYmlpiRZ1/ZNrUkD4coKFg/eKyg4f1r5JFArwHv5btUfVUEJePBeQcHF8WlVDd4B 7qnJSTbo4xH2/Ae/2IrVOZZfIPpcFEfnYW+Ampqa7LqZkKDP2hgZLI713t96bEsAlnqans80zS17 9d7CrjtjX8vQzl5FigfvFZGaP6fcEvDgvdyiitsDPXiP26Gv8I1XNXhPEl0mWX4Clz/4gX3y4wTb ol1T69SqsTbfiqPY9g5413/hMBTFsvCV7dFW4SHwJ3oJeAlsogSSkxJs3qKVNnXectumU3N75sbj rUE9+apVoHjwXgGh+VPKLwEP3ssvq3g9MurBOw6/OBvjTOspCFGhptUF3q/530f2xpej7dSDetmd FxwsOkqBmHHRS52JisHxnfAS8BJYrwTSM9Ltqbe/t3tf+s76dG9vj117jNXPUhCBCpToCRVZgc5v 8ilEZiAqCBlXCetHqnniaVdnITnLDjuEoj/4Et0SICILMdvRFzLYEk2GWNlVXdjqJp47icZ8qT4J EImFOOhky2XM8XOgBBmf+a6qChmZ0bUgjvvmXIcILGRb5j7IDEwUIl8qLAGoKMD1YpmxsWb76mXg dcDrQEV0gJmksnbD4gu8E5KQWOfU774LxXd/5ZXqAWS8OnBsfP55s4ceCr1IAPEkUerdu8IvFn9i FUqAzJdk2kVf+KQGybkq87LkJiAbbgDW0QvCkZJJ1ZfqkQDO6I88EgoJynj/+GModwPhQln0Ex89 SJpV2T0iXCjJ5Yj1TnjXzS3EcSdp15dfhu7j2WdDYSQ3pRC2k6Ry1Kq6703pTw0fC1cVygzOn756 GXgd8DpQER2Qt6rAe+Xs3MUXeCciCNvfJH4ioRMJTkjQE1jYeEmTbROLPJawwDoOqOLffALoSltf efHzPZYzMr0GBUseWVdpD4s7XkQA9//+N/RCJIESiVnIihnZJn8H7QV9o03+xjJIW0EFVBDbm0L/ sdiSCdSXzZcAuoL1feTIUNIkxhEgxBiTuAr9wKrJWJDIifFlDBgjEmShS8Fx9Ibf0RXAObpC24C1 a68NJfwiMRRgkYhGZGslr0BQGPtAJ9q3/+t7xpprkGyMscfiGhT6T9/oN3pSGcBw86UafS0gJ7IQ szAjfjpJui69NBRLHys2sdMp5EBgbJFlkCiN38mOioypjDu/Mdb8jfw5nmMin1HGCj3gd9ogydZ9 94Vi73Md5o1IHQocD2m3o8L/oT/oF20wNwX9QQ9Y9NHGGWeYnXBCKM8A+sO16EeQrTloP8hJQXu0 iy6zM/nAA6E+MVfSPrrO/QfzGfMbJXge6Adt0C4x5bke/2Z3M4odPaNPIX2PvAS8BLwENi6B+ALv QRg/rFDbbx8CT2R2BSxhFSd1+UcfheK4k5mSTJUAHjK9khkRyyufn39uttdeIcliNcXKhRUfi93g waFtdkAYLz/OoT2yxwL+997b7MgjQzHBsZBR+ATAUUgGxa5AYPH94ovQNShXX/3X97TJC5/jABqU yy4LWdt4Yfqy+RKA34zOoCcAFihXABas5B9/HEqwBMj69NOQ5RQwT9ZedCHQF8aScQO8AKzJfIue cMzjj5vdeGOIokFhHI8+OqSPAPlDDw19jz6R0TXQMfSNvAMUsnVG7g5wDBmASfRDlld+e+89s3ff XX+M+s2XUuy3APhE1iT7ueiiUOZbsu0ecURofgioLABZ5MmY3nprSBcA5swZ7JQgY8aJMeScJ58M 6QFj8txzofbICUDOACrtoEeA8Z13Dlm5SZp04ol/6RDzCccxzoBs2mb8uSbzELpE28GCnYRMGCUA 6GTupR/MY2RpffTRULvoMouBt94KZV6FEsYOJH1nwUi/ORawjpHh3ntDu4N8fvZZaD5jniFbNXrG 7iHt0k/6y5yFzvFv7p+2yfzri5eAl4CXgJdApUggvsB74GwGF5QXERYiADbxuQE6AHJePFBbsH4D 0rA0YbHnRc2LDss5IAzrHCAZAM2L6ZprQi8xLF5XXRX6rl+/EIgfMyZ0LinRsU7R5i+/hF6eFBYN ADl2AVgocD2AHNZYLGUAe4AhFjSyLb7zTsi6Rv94WQMqscryYiejLVv/vmy+BNjeAryjJ1hmAXYs +rBCMq5YZNEpAExALWDssDr++msI4AGAAGXoDOcDnBhvwBgZNYcPD4EmCmPPQoAFI4COHRWOB0zx HYszdmqwol5xRegcAB3WfhabgEv0D7AGmIOjz0J12rSQ/g0btvkyqY0tIFvGE6s7NJOgBJmWA6vx hAmhMWXcybSMXmApB6Aiexbo7IrwPKI7LO7QCxYCLNIYSxbiPJ+AXfRmxAizyZNDOydYvCnoF885 usEOTLBLh04cdFDouswBs2aFFpbMWSz4KGRhZQeB8eY4FgtU5g70CCs4/TjmmNBOzU8/heYW+oW+ sai4557Q3IM8yCLNvMaciV79/ntormI+JGEdFvrgeWDxMmhQ6LokLWMRxKKBc9FRX7wEvAS8BLwE KkUC8QXeg61naDPXXx8CTwFtJtjWBrTzcobaAjBfuzZkveIFizWKlxMvNUAaL1yOnzQpBPifecZs +vQQcGJBgPUUsM8LHbAGcF+xIjRwvHjHjQv9Dbjnb0A9L+3Ro0P0DCxqbN0DAgIAAaAAQPCSBTQA /LDcvvBCaPv65ZfNli+vFOWI+0bQF4DJzz+bHXigWf/+IYsnQAidABhzDJX09AA2xgnAD1hDf1iw BSnuAU38jeWSsWXxhqVyzpyQqAF1gB2spliB0T1AEIAc/YATjV5wfECB4XqMN8Ae8IjeAcLQMxYc gDgWEIBNKBG+/FMCAF9AKZQmdsGQFyCXHQ/GOigAWuaA8eND4w+o5plFrlBEsJoHCz7OARRDufrP f0IWe8aWcWWhjS5gIWfHJnheiWZDYUx5zq+8MjTmHMcijcJ8gH6xg4eBAODOnIT+UQD4GA3QvYED Q4sD9BZAzcKQeQxdwXgBMA92dLD2My+SQfjMM0NzEtmC0UHmGnSQwvzE3IceYvhgLkRGLBrYYQoW oiyCWGBiga8kjqdXXS8BLwEvAS+BkATiC7zz0qHwAuWlyYsGUAYFgRcgL0VewryMeUmNGmX222+h c9g2BlzhxIYViZc94BnwhaUNyycvaGgUtAuAx0EW8MfLjWNYIPASxmoVGW0GCxb89w8+CF0TfjVb zmxNQ+fhuvSNdgLefqDBgEAyvnJdXuwAQ/+yrJznO+AG8wkoBuwAkrC2Mg5QJR57LASkGVdAF2PE 2PI3llV+Q5cWLQoBMb7Hwg7d4cEHQ2ArsPDefnuIX8y/ORcLPhQJrKMsMtE3/s0ikJ0bCtcDbLKA ALRjiaW/gC0oWPyb/rBj4OlU69cLqDEsvhlbxpPnDkoKz1akoydjF/gp8Fwz5ljCA9nie8AxAec9 0IuAdsOOCc8mwJZFPZbsYJeMMaRtzmd+4N8cix5Q0TfGmgUG+gegZhHPjh/9DwrWe/rNHHT//SFd Qfc4Z82av3YVmZ+4Nn0B3LNLgzGD7w8/PLQwYAHI+cgGMM/8QvssPljcYKhghwm9457RM3Q90Es+ uRfkVBlRdCrnqf5nK/Q7mvtXVfft2/USiDcJ8J7k/VgLfHCSblEpa/yGjpluIyfOsU6tG9l+fbtZ om6cMDkbLJqsEzXRp2i7NiGwCJV1ker4nZcpLxOAE+CHlx4vngULQlQGKCcMKhY1vgegA97PPjtk VRs7NgT8AW0AL6xNM2aEfuPlipUKAH7zzaEXL4AL6/zcuX/xjnlBY4ED7AO6g/jRvAixovEb7fHy 5uWJdRZuKYCOFzcvYixoAeDD8gUoA7xjOeN4XsJRUkr0si847rgQuAx8DoK+oSeyBKbQ52hccKAr AGgADvoSOC5ikQzKxIkhYENFr9gl4V7gMjO+gGhoK3DdAToUwAKygFYAhxi9QT6MG4s32mQXhR0Y QBg6xvHoGCAMegIWdcAY7aMn6ERg4ec69JkFJ5xsdATQj2U+oFdEiX7QjWItYArRkUAuG+pbMK9o dykBmVVm4Vlnl4TnGyCKNZw5AbnxzFKRMc88wJVnmjEFAAOqg90SrPIs4pkrAOuM5ZAhoZ5CTWER DwjmGiyu2FnBOs58w+IQfUDn0AUAOv1hjGmHRRwLe6zoXB+gjcWcttAVxp822NXjHPSX75nioUxB 8WI+ZoHI/MJiESoQO4OA94DiB/hnAYOu0SZ6j3GDewsWF/SR+RKdZ4GDXtF3dBRZ0VdkA5jnfO6l EncEi/V8OJ0BdDNfVvRlzMJCckngGQp2NzRUZFhN1DP59fApNmHaAtu+ayvbq1dXF2kmGqeqynwU fFteArVSAswR7G4yB2IQYT6kVnTuqICQyK46csJs+2nsLGvbvIEduPu2lu4zrFZAkuU5hUGGsjB1 agiMR1thF4CXJrsF7CBA64ii4pM0RdFgRGlXoj5JU2XIDXDPwh7wzQIABAjoBbhjvWdRXlYBtAOK OQ+QjpGB+QkOOj4yweJyY+0A3OkH8xlcdBZ2MVgqJUmT5JegsUjVLmyxZOuMDCwE9EIPMqySpOlN JWk66cCedvt5B1q+FlU+SVMMKozvspeADAsJopymilJYJNpiIcwIjCPMm9UE4LPqptsTb/1o97/y vU/SVOUaiQUMi3ikI1uVX3QTLgAowFoP5z2g+GzC6f5QLwEvgWqQAKAQfxQcTfGRwdKPZZ9duvIA d7oI6GfHjx0AdnPYpcEJFapPeYB7cJvMZXDicXaPxxKmPyVotyBNTuSpOAWzy+CpM/GoDf6e40kC 2qVMVCCA9LPOshTtfJew2xax4xZLoogvzntFRoYtFg20e8lGY8ECxwqSsHDwsn3xEvASiD4JYGl/ /fUQVQaKyh57mGHpZdesvAWACV0KPx3Oh6uOUzKUmvIWgD/nwbmPInpdebu/2ceFaZGJklm6Agqk KDRmCQaQGH2Bb7Y8fANeAvEkgfDznyAKX5ry66QRJYwSg1moqw6887LC2uRLfEugNM+9tDQio3PE t6Ti9+43ZZ7w80r86knknZc1r6xvnpFPRYmoMkly/E5XPoZkeP2UwNkWnwuAfEQt0ncFCYlWvJ7f Sh/r//132Xl5eHlEnQ6wuxaOOpggn7E0hdtOk9N/Av5p+OrEUElQqtaNeJ6G7uTeQV/ZE+8MtYG9 uthDVxxuSXLmKSiUA936iporkRCS5MCXuc8+loC1KB4LKzwqioKIcYwoW9S1S1K63yJZGbNx7OOh KbW1j54kKzpOJuH54k02jLTXETfuhbIi56AjgKggXOJ6wFeJ+N1JooZlyvEzIdJpuDKfmmBMAg5k kBuiLP0Mjg/C0Zb3vMrse7y0hc4osVSOuPtseyfAW90YZ5WxC2+PJ8vZO00hLBOhGoYLgD5PoYHz BegTWBTo+CS1l6x69ROf2htfjLGTD9zJ7jhrX8vXuBaV+caMl4Hw9+klEEMS0AI8QU726YrylUzU wIhSeOyxlqfwuUUKMgCoryo8Upmc98oH7wgEISkaRIIiGSSwNVtNzgDRpEaJksFKRWJYqWgVGcqs 2kgJlBKw6JQFAqLpJja3L0RmUFSKYhIUUUrfuwB9ghzmEoljHU9yCcsVHVklK+AKWQDTFZWosRLn JABg40kW6Igi9BQTdWV9OhKpg8wrirLk5pUqcjJiTNYqqsoyxSdPUb8an3CCJSsSTEkAxjfwTCQI tBfKULFEEZ8KpdONFCO+jmLAF2+qhXhzn7l4OD/QGeYV3i0be14wJinqDuOTIp5/mpLx8QL/W9GY F+v5KyaKULgttao4ygk2df5SW7RsjbVolOWirRXTXjzI2N+jl0BtkwBzhfBokvyN/jEH6F6LRCfM FZ2wSBHaeM9sVhSrDcgu+sE7E6CAWUkM8ogqS19lZ7ZZyoY5U2EeGyr1eTdxW5Pk7Sz7e3wVwrAR 1g+dKL2I4zuB1ZIg/n58ScbQkdlK/DNDtaGiBXWTY3SSnpm41ZGyxh99gfoQmTiprHM28XfGZJEc SacoUVG6IjltrTwOGQpLuIF9xnWti3BhuQo9O1EvgGw5Qm4hR9KWAv7RE7R1EwUR7YdLF9ZZyDZk HEJf2AqX31Kq5uE0ElNtimNvtMvA989LwEugUiVQLOCeJwBPBDQXUrKSjc/RD94DccaTBTFShdhy 1Utj9uWX2wxtxzaSQnRTXPdEWfCKoynufaWq/UYaK2vnJR71JNCRq66ymXKaaaDkYN0EFJPYqfA6 snHNrEJ9SRY1Z5GSaU1Rbod0/b21dkYyZEEvgv63EZCYpGNzlbNgoihA2bK8d1UEmBZKvFYQr7TB 6phbyphXoOUlKpIPvNYUYtf74iXgJeAlUIYESkSdydVCv0BUGrfDWxYtbxMkWpngveocVrmhSP5o vP3N/Wurlu3XdRk3NyITtnWTtFuRLGoNn/y71sivLOWON90I7jdCRxKCrKwb0JFAN9CPyArNo1bo SVk6UmpxzD1z75X+zESOCX4aAUAsS0fD45bAsxtuw3W5rPP87xWX0YZ0RnOnA+6i46UrCpcH7pvy cPljvQTiWwLEgieUZCpheZmfq3Cnd3MkXbXgfXN6FkfnJgHAVHK1wlstr+ccWV7xI+b7hLKs1nEk p3i8VcYfXUAn1op+FFnXyLEmX5aBeNMTZMI9F4uSlS1uIs9Mnhxdg+/jUU/8PUsCYbomL9vkn3+2 DPwVyOzqi5eAl4CXwCZIgOgz6Vdf7XbtHO2XhHhRVjx4r8EBCcDGcsUcHat06t/LwfVLOS9+q/Tq vymqxoIFC8LGO2fL8yUOJQBILVQoxWFKb/+VnJ+/Fv0qqPz7J2XcnD59ugOypHOv7YVnhjpP/PKR I0e6Z4Vn5gfRWybIkXWF0twHi+HaLgt/fxESCPvPmJxTkxRJIv3kky1J+uGLl4CXgJdAhSQgvnvq /fdbuuiPCeTTwX8mioyptf9tX6FRq/qTACCArUXiZALcsRx26tTJevToYVtuuaUDKHw/Y8aMdRbF VDl3BuelQK8JW+yrvrf+CjUtAazLmXJm3X777W3bbbe1bbbZxraTL0UD+VFMFtd6viaXSN0oDeTR FXQmlkuwC8Vi5XdFDEhT+L+tFHGEZ6aDnErZifj111/dM8X9JovCUvoZoQ3k4He0YlkTSvUd4C7Q TkzpFPkrZIgqkzh1ai26QX8rXgJeAjUlgeRXX3UJ3RJlHHIW+CgxknnwXkMaEdAhsBay9d+7d28H yLbYYgsH3nfYYQdr3bq1o0lgVeVzjrhYWGE5Hssj38UbZaKGhqvGL4u+NJIzazeFVASwUvm7Z8+e lq5oPVPE74VewyIQIA8FCwAfAPpVcpz8U1FQihS6MFaBK2Ac3WdXqp4cRHlmkAHPDPLgmalfv74D 8chi8eLFzhIf3C+fBbKmIAfkE6tyqHFljKYOANx5oWpeTFPUprRLLllvGLho6nJc94VwTl1UY9uO UL4hVNRf66waYsXWrsJ9pdeuW9rY3SQT8lt5IJLEjnDRzjCcVmHghPJI1oP38kipCo4BXAAeGjdu 7D6hyACwABcALEA5FlYqFnfA+tChQ2327NnOIg+N4pdffnH/DqgEVdBN32QUSYCFG9x3AGzAgcfK jM4A7AMe+LRp0xzA5XuszFjtR4wY4XQoAPRRdFvl7gqLWO6nSZMm7v4B5yxgkQvPTB1Nqr169XJW eAqLGOTAggbZUJcqxjffBQvfcl/cHxh9EuDlqUUcqc7TL73UUv/zH0uo7ZGahBtsgOoJqvuqboiK C2DcXvU41aNU26nWNPuSvt6uSmLbu1Ub15BKsXDYLSybf4Xlg4yQ6Y6qlQG266ude8L3eps+69XQ vVbmZbdTY7eovqL6heo74fHcszIvEr1tJY4e7eh4KUosqW3wUOK3GgTwHrzXkK4A3gEjWytEYMeO HR0NAP4y2/5YUQFakc6IAHSOhx/fuXNn6684pAA2KBPLlG0yHvjONTRUUXFZQCtg9DPlC4Dr/s03 3zgfidGaUACzWJ4DAIs1euXKlY5yBbBFR7Ba8z2f6FEsFu6PhexOiokPUOdZ4ZkBjE8VTYKFTMD9 53lp3769u/9g0cIzx7PCTkWW+IuxKodYHLtK7zPcUwF3MqUSGYIETC6LdW0vp+gGX1d9XvUtVSJg tlrPTR+p795XHaT6kup/VZWDapMK4H9/1S026awNH0z2+YNUO6oerNpoE9oFUPdWZcHSZhPOW9+h A/Xli2EZvqzPN8IVUCpcZjtvZvuc3iB8j53C98y/Y70cqhu4WZUFTzPVA1WvV0WGjGsclMRZsyxd YYRTH388lDUeul4NAXgP3mtQ4QDcAAloMgAStv/5N8ALwDV8+HD3N8cFlnqoNNSmJJAR8AekANIo ngZQg4NZxZdm/AGsbRWDFlCKnmCBR2egi2RoEgGMAlYB8/DhoY+wEER/OAbOPAA4lgv3AjWG+9tx xx2tXTtMiuYs6ixkAPIseikc10JZM+fOneus7+xEcFxDZU5FXsjUlxiTQJCoS1SZxFGjnCUsGUtY PBTe1u1Vm6pCycCae7Tq8aVunt9PVe2gCugVvnD0jfVZ6fl9fZZmrPTKaWVkkb9gA8LlGGgwZVmq g9+Vdd5WhNvi79JTEffHsetDJQ30/QuqH4XveX1d4jz6U9YOQ0Mdw4IH2sdi1Z9Uh4fr9PX0a33X Kn2N0nJgHanUEK6sjPib4zZWuP+yjgnOD+RVVntlXNLJvKwxpA2s7eerHq4KkL9DVYFYrG343/FA hdKtkhU+TTt9aTdrJaN3CmFpa6J48F4TUtc1ASHQZAJrIRxegEh3JYQByLP9DwiZOHGiA1wB3QHQ BkgDjGCNBYBgjQ/AfQ3djr9sFUsAUM5OCxx3QOvOytqLsyp0q9I8dvQD0ApNZNKkSQ7MQ8+KZeAe LEwB3+g7OwiAcHahcOKF/86zw+5EsJjlmUEOPEcLFy50VBlk0KwZZiMMJh68V7HaVn7zZGTWIjT5 889dKMgkRRmKm4K65oXvdq4+qRRoC9A0gsK/91YtVP0j/CXnRW5MYE2/SvVdVSz4ADEs7ZSuqv9R hSYBkKQ96C5nqrIAwPJ9suqg8LlYXqHnAOIiS2v942pVdgoeU1XSSot85PgbEMzC4ixVrOFvh9s9 Qp8tw4310ucNqixcAIhY7enfsapiLjgOPaCSfnA+uxFYgkOP+T8LaY8DOb6qvwGih4TbPUafo1S7 qyIT6D1QaSgAXBZLj4avzXcdVC9VfVOVttgZYfFUemrZXd8hA6z7V6qGbA6hwmKC31ks0Q73gIW7 hyoLL0rz8Hm36JPxYfdgkCr3fLFqIKugTXYPHlKF2vKMKtQd7gU5BnJhV4C+cwyV33cKGljPJwsc GZztU9Vvw239HD5ua32ubwdoI83F9E96p6TKxyb94ostQfTNmohE48F7DWhQECIS4AWPna18gFYA JgAmgC229gErWAwDWkzwN/QB/g4cGQMH2Bq4HX/JapJAsGjD4o4VHeCK8yUAPVi8BQ6qM0UnwCmz a9euDrjCD4/l6ESBXwc7CexIAcgjd6R4HgDl3CPPEwWgznPUsmVL5+yNLwAyZKHsSwxKACcxqFPK lppx6qmWqN3JuC0A0PGqgFA48PuEJQG4PkkV0D1C9c8ICQHeAcsA0I9V4WRDfThM9TpVQCNccIDr jaoBzQZQDz3i36oAbUA2FQAP6AW4Q815WjWw7m8bPgZACM3iPFUWCbQdFPrOIuJ9VbGe7ERVgDT9 f031/vCB/fR5iSp8fwr/vkkVnjrtfaAKoGYHgv6cpsq9AL7LKuwALFddorpIFUs8su2merkqiw+A L8ZV2gUss1BgEQGFh50JKEksNgD+g1QB3iwqggUCiyDuHRlwDCD9TtXAen+h/v5OFVB/WLjeok8s 3VyDAnjnONqG5sP9ISdk/5Aq40ehTb4DjAPqOf90VUA793KJKuAd8B/0ncUQld9ZzCHXsnYvQI4s qoIF2+/6O1LXwt2p7R8pzz4bim41bpyLdlWdxYP36pR2+FoALYAFFAi29uHuwtnFoghNBsBOFJqA 305IPM6hzhLnCsAGQMEqTwkc9LwlsQYGs5ouGYx/cDks8dCn4LoDTFkIBqER+Te0K8AsDs8AfZyc Y9lJE9ANMO/SpYvbdQLAQ4chmgzPDPc/fvx4d0zwPHAOoJ/njIUMFnmAfLB7VU1D5y9TGRIgWZmo TsmffmrpF1xgCVqQxnXBCgzv/TdVrLM9w9LAKoulHKv7k6ozg5eOPmGTYTXHas1xUFCw7gLCBqsC pK9RBUgC/AC0lEmqWFwBd9Aklqo+odo3fD7fs1gAEEKpoGAVZ1FBeVYV7jyOqsEOQWCZ5j5mqgKA sRbTn7tUAb8A8QNUsUbzXU64PRYlHM9uAGWWKmCY+8BK/rAqlJjDVOnT+kpwfXYThqhyz2zinBo+ mAUBCxQK8gQcX6EKXQlL9teqt6iyeJijyoKIhQeLIugykcgKWwFAmcUF1msKYJmFE4X7QjY4zGL5 7qc6QTWgP7FoYSEQYgOGZARTjMUTCzgKC6RdVRkHQD7jzIKoj+qRqowbixLGF9sGi6ptVD9X5ZrI jb/Z3eB87nN9BbmyY/OJ6vuqW6qOCf8d9G8Dp9bWr0kEl3bllS7KVYmYEdXFgffgvYY0CmAB75YY 1VgHAeU/Kysgzog//vij2/4HhGBdpQTgBd4zoH3IkCEOtADeoA9457saGshquiyLvcgxDhyecXZm AYhFmggsgFm43wB2QCvgFR3ifJyiAf2x6twcWNKhDXFfLFC+++4798wA5omqg1MuVJlAVpzD8wHF iO+gEHH//nmpJsWtrMsQnUuLtiJRCvMVsi2akqVU1i1uUjuAXvjZARjEWoqFF6srABlQF/wWNIzl HUDYMfzFtPDfAL0V4e8AhtA4HlFlYUCBIoG1eYjqVFWAKtZjQGUH1QaqgEuAY7CICGgc9APgDTA8 VxVQSsGyCxBkYQCQZTFAvwGPmarw4bHis0CYrcouQUATwoqNVXyM6khVAD6W/8aqHVQDqkkT/c39 bKxwTV6xgFBqsHPA/QT95j4vC/8+RJ8sFDgOqgiFRRKWcAD6Yaq3qOaqsgChyCjrgP/rqoPC3wHo AzrOffqb8Zuhylggg8Bqz64H98ViLKA9QVXBSs8uAFQdCpb5oD8BqmP8qID1wB/gV/2NbEOwIjSe wTXZgaCwsIvcIQl/7T4YM+S9nyq7EexKBDsQkcfF0d/FwmkFJ55oJXoPJ4gNUV1zkwfvNahkAIu6 crwKOO6AEjjNwb9xRgzC/wWWVyyH/M5x8OIBaBRvda/BgazCS6MjWNThuEOBAXwHYx1EX8EZld/4 Hn1hQYgucR70EhaJ6Au6wzmxqivBggVwjjx4DoJnIXhm2I0InhXun10rgDpyCKhosXr/VahmsdE0 zmHyC8p98EHLu+UWx32P28IOPWB5kOpKVfjLgOPAmvue/gaYBWA0EBSgGfBGgcYB4MTKDO0DcMiC IACJpT85B8B2rSqW16/C52PNDRgDgExKQLv4I9wm3wVW+6AvWGoBsbeqfqaK9Zn+XKQaIBOsxRTa X19/WCSwkIBiwgLhfVXoPYFlPbjX4JrBZ9A/rOtYrKlYqQNrO8fNVIXfTQks0Vjc+X5vVWRBGR3R ONcrbYFmfAIwzm9B34Lv9tJ3AHvaxnJPHwDtFO4/OD7oM2A8kHNwLY5BPhzPgogCVeYbVWTKgobd hfnhvwO54mvANTmGhR/tsIjIDrdR+oP74/oU2kP2izZwbBx8jTEh58UXHXh3oL0aA0JULXjHISxe 64YUt5Q8igFTAheZAlgtBUrIstq6VSu3te+AVjj8GZ+FenlxfCNZEtu0aeNA2bpj4lXOsXzf5dAR xh0rM+MN+HT6EHHP6EOWFoDoTKo4d3XCFncXCpGJhJCk+qynfwPeAbSl26jxZ3QTJ/nAgRvuOotX npnmzZu7hUuwOAlyJ7AjQQSaYJeKnatYdtzdRFHVvsO1u5Qg/4b866+3PIH4EkXdissCkOPtjWV1 bFgCp+kTrjYWdcAYAA8LfekSfIcFGyoH9ItTVaFeHBQ+H6txcFwkAIYaguUZKy8WZ6zwWMUDsBcA zeCagGssxxR+CxYTQZucf6MqlmCoMFigsfoH4DJoj3sN0Epkf07X91ihuQ6Wcs6HphMA/dL9CfoV fAJmsewjM+rqiAO20t9nh/8dgGT+zQ4HuwDBNaAbBYX1JP0MwDXfI0cWWsHfwbGAd3YHWLwgd1w4 WHgwjpELgojm3Z+0FYxN8Ml9ck3a6xLuG4s3Fhg/qkL7OUMVtlnQR9p6XxW6TqADjAd9CTFy/1lY gL2gykIL2taaDRwXB18X7r23A+7Fe+xhCQqGUJ3AHfFWDXgHXBDeUC/XuKwCSm4hDADnE8CkbfsS osOsRybFOr5QoCJfYDxPlkI+i/RvQhC54/VdosBJmqyK2ve3AiyqtB15TLzKOlbvu7SO4LCsbbf1 6oiOZbwLBczXpz+B7qBHRQLy6zuWYwoIjxjoVDTJrQKhtgK/EZy2sarzGVjUA4dwnHTh+hMyk+zF WOU9cK8Fb1USMWkHqkDx3XPkMFasHcq4K4B3rNEAtldUeeEENA0somNUA8CIcDieCjjFEkwB5AFe 4U+PUoWuAYUFVAAwDYDhLvobKz3gHl46BdCGU+lHqlApAlAeWIeDa0CjuV8VbjmgPKCK0D79g3dN wVH0JVWs5wDOwNIdtMdn0B9oGliMAZoBvWOe/gZMQvGBCrO+RUv4Uutkwb9p63rVm1ShgFymCgUF GUDNoX9YsqG9LFBlo5tj2FGgUvg3lXuExnKHKvcQAP7gHjg2GAf+RgatVDuE2wFkM5bcC06lwfHh P9ftZpRuj9+DMYP6A+2FYxjbX1RZCAC6AfaUVeF/8zeLJmTPTs0wVSg0LNA2xHnnexY16Apc+tDG f9wVqHu5zz9vJXqv6AVTIzkmEvTCK2ttavcO+sqeeGeoDezVxR664nBLSlSa8cIN7EfhWClwmSD+ aZIygMJTBMjHVZGlNEn3PPell2z2e+9ZA3GOuyr7XyLgqwKJRHgOC/SyyhdASQfIx5s8a6nyYCme +8orNufdd62+eHNdb73VEgW+K6IjMSsiaEBamLL96OaJCjwf67t3ADwUI0A9kWgIqwp9pqzpLlkL iUUChH+ceaalKzRnN/mWZMjpt0jz2Qa5jNCVdF6ufAomKXlatpxnt3jiCWtxzjlWwHm+VL4EeG0R 3UEL0kQl6iJkW9JICNC1uPAaxcoNkMTJ8RBVqBY7qEIbAfBhzcXCCogEaGGBB6DCPT9MdY4qlmra aBA+Hmssf0NhgUIDKOP1Dg/9HNWgAARvDn/fUZ+AWa6HZR0gDojnHID+7qrPqUauq3gUpqjqUbff VQeoAjZZPAC4Aa2gEf6mLRYnAGHoHywOoJZgFQ4K572sCs2EvmNBpx8AZ6zLAPirVaF2RBacaQep BoudUj87edEPZMrLF6s012HxcWH44IAuAvBvWKoBLP8sWNjZwEoPeGZRxP3hO/Bo+HjoRxzH8aeo wpPHos9mEmPNfQDAofMwlizKAPt8HqEKfYXr3x5uj10BrOLvq8JLp7AjErDLAOm3hK93QfjcRvpk kYEOcL0GqljV0a2A1hNuyn2wAOD3HqrIaE/VHyIPqN1/l7Drpxjv+deIKyZjm6JAbJKDalbddHvi rR/t/le+tz7d29tj1x5j9bMCJ41Nk13VgHdZ9ZKUQCNzr70sQU6VcVkEHvL0guF5ZA7K0L/dgrns tdL6xQWwoYapEHEp09p205WtIzEqn0JtO+Z8LOIl6aZZ7FdSYZEbOKeW10HVg/dKEn51NcOcqF2l BDkvp11xhaUo8kOtLgC5XqqAd3jigD0cKuFgA6gBiIDagDKzv/7GugrQBoyuCL+Q+ukTqzXgC0vz CFUA/q+qwRoosK4CsmkPMPqOKtZ3QDQWecDlm6q83LDaYsHHgkwBpANa9wh/r0fcWasPUwV4srCA HkP7AGas9FBXcP4EcNIvrMH0jQJVB+v/buHzAapY2geqwvXfXhW6B/ffQJVFBcASalFkQU5ck2sA QCMt2Uw/WP87qbJLAHyhn/C6W6gepoq86SfyR34AZcAsiwfu/V1VFiocyzmMEccCpLmH/uFrDtUn wJ7xof97qTZQRYWRIwsb2sEqDpgHUHNP01UB0PR1B1XkgRUfHwR2U55SZSHHQm+IKosLdgbg9S8J Hx8snrbVv/upsihg3MeqjlFloba+Apg5TPUY1XGq/1NlLOOgsGuNr00+0a6Yd9gB3MQS/eBdN5k0 ZoxlygoVt+B9EwfVH+4lEK8ScOAd0CWrRmWC94rI04P3ikiths/BUUw7Voqha2k33WSp2jnxpZwS wKINiAWcbqg00A9Y4ktvIgEkoc+Utd7muKVl9AcAjRUYSkfAd9/QKRyHVSzSqRIrOyB1ebiv5bz9 SjsMazlAP6DKVKRhxoKdgxUVOTl8zuP6PFcVXIkjMYsXxu9u1d6qUIBYbMyMuEagA1jmy+RhhM9j AQMVJ05KMY7yd91lRccfrzHWICv0cEWiylQmeK86PgsTqugzvngJeAl4CWxUAiTf8cVLoKISYDcT epIc/nFizZMzq4u37EvZEgB8bwy408IK1dLAne8B5GUB9+C4snoCaKS9soA77WDpLR0NhcUFVuUN sHnLuvxm/w7w3RzgTgcYC2S9OQW6FFZzkN1DquxcsOOChR1r/o2qs0pdINCB8gJ3To8j4F6kDN65 L7xghQB3QHsFgfvmDOv6zq068F7ZPfXteQl4CdRaCSQIwCeIw1zjVRKmL77EoAQA8ALt+TffbHkP PBC/kWhicOh8lytJAlBxjlSFEw9thk0oogNBSzpMFUrPpoD0SupWrDZTJPYIEWWKoIArs7mzumOY joLiwXsUDILvgpdA3EsAR1USXNR0wYpbjbF6a/p2a9X1eanygpUuFZx7ruXIaZgEKr54CcSVBPB7 +FQVh1gcZG9RhYs/J66ksNk3W3DccZZDRBlZ3l1EGd4LUQLcubmqcViF867YypkDB7qUsb54CXgJ eAlsSAJ5mhyn9+tnq0eMsMSKOnRXknix/Bcou/HaqVMtVY73W3//vWVst52PNlNJ8q22Zgi9quhe ycrAm3b55Zb0K56YvngJeAl4CZQhAQH0fEWvyr/xRhfi20WUqaRSmZx3D94raVB8M14CXgIVk0Du VlvZOAHlpcOHbzQ8c8Va3/Sz2I5kY7SO+tX1o48sVUmgirG8bMjq4kNFbrqQq+OMcCSaxPHjXSSa 5C8g//riJeAl4CWwfgmQRyX/2mst/5JLQj6bFYgoszHZevDuNc9LwEug1kigoG9fW3rnnVagXbqE SorzvtnC0RZpavv2lrG1YrvBgd9Yvzx432xxV1kD4Ug0CXPnWppeyinKq/CPomNKFC/ehSqNKCzg svOUBKyg0NJSki0jTUn2qqyjvmEvAS+BKpeA5mqXDXU9FM0SZSnP1XuoUAmYHEUGx9RKLh68V7JA fXNeAl4CNSeBwgEDLP/LL0Oxc6OoANSKsLiXReXx4D2KRm0DXVEoyYRVqyzl9tst9X//CyUPDBeA O9vkhYcdFgpVyngqESFJ1B578wf7ctjvdsBu3eycI3dV4q8iKypLH6JfGr6HXgLxJwGFIk5YvtzS FPIx6ccgGUFIDMVdu1ruww9b0X77hUB7FTmmevAef2rn79hLoNZKoBCP/g+VCYU471Vg7aiw4Mrr nOTBe4VFXK0nYl2XRS1FjqxpSrYS5CApEbDPE6DPP/XU8Ju82JK1kCTQ8aX/+9he/WyknX5wb7v3 3AMUDbDECou9/b1ax81fzEugMiSgZzphxQrL0HOe/AGphEOlcPfdLe+//7Winj1DEWWUmbuqHFM9 eK+MgfRtbL4EiKWsBDvWUNkx4Iex1aQU8TaatHHhsoXyYyu9vEuiwnaVHJltmtLT7bCDMsgphVyQ OVZWMffbbKWp0yrY/c5vtAtlQY6Dpq1vX2qfBP4G3isxw2q1ScqD92oT9WZdCIu55ixSnCe//rql X321Jc6ZYyXK0MrLu+CMM0KLR803SUkC77K8X/O/j+zNL0fbSQf2tNvPO1AUmgJNcx68b9Y4+JO9 BGpCAnr2ExYtsnRFokqWLxOl4KijLO/uu624c+cQnaaKaZuVCd6ja5+6JgbUX7PiEmimHMxPP22m F6E99JDZM8+YsaI9+uhQm4qNam8r1/X/KV+1tqTsHeXWvvfe0G96gOyNN8xkBXPncoxiMzuwfuih SrmtnNtkSrz/fsWrVcBawLwvXgJeAl4CFZUAOykC5wmqhYSBGzTIirfZJvTSrkJrW0W768/zEvAS qHwJOOu6Sv5551nuk09aCcCdHBFVDNwr+048eK9sicZbe1jfFVrPtIK1554za9vWbO+9zeS1bQq1 ZMRIBYjvv7/ZddeZ/fFHSEJB9t1bbzU74QSlllZuaYULNIV3W1defjm0AKB++228Sdbfr5eAl0Bl SwAALz4rL3ASr2STOfEA5YvHgS3K4jhX9q379rwE4loCPPva2S0WUyBPu255MiSWwBoAuMdg8eA9 BgctqrrMNrO2nQ0PbXHHXJk82axXLzNFETHF7raLLlLKZuVs1vaUXXNN6JhglQswx1JPpIeffw5t WwcOYTvuaHb66WakJW7ePKpu23fGS8BLIEYlwEtcQD1BzsglPXpY7uOPG5kUnbNqjFnfYnQEfLe9 BKpfAizQcU6XETH/+uvNyOhNQIIYLR68x+jARU23sVZhZd9nn5DlClqMspJZixYhB0R46uKZ/aMA 0Klw5uGacq5eos7LO0hPD/f9kENClvxGjaLmln1HvAS8BGqBBJh/FMe5pGVLK8b/JpiTasGt+Vvw EvASKCUBgXfiuBfjgwfGYLFe3qAEUShMn6QpCgclZrrUrl3IWg7wxno+bNhfXYcug1MID8lVV4W4 8DvtFAL1AZ/9tNNCv+HMqugP9tprIQoN38FzhwuPpR5A78OzxYxabGpHC5WJOf+rrzb1tKg6Xlpu OXJ+nLDLLpYtGllX0TFaKaqBbD2+lFMCzg1U3PPiKLCAl8thlTlJTvWJovpFW5jTcoq8xg4r0Q5H ica6JBYd1GtMav7CsS6BynRY9eA91rWhJvvfoYPZhAkhcI3lHYpMZLnhBrPbbgt9M326mTJV2uDB Zorr7YC6nMbsrLNCIH/IkFD0GbjxrIzvuy9kiT///Jq8Q3/tapBAfu/etvLRR902ptOlGCyJbMfO mmXTtCDNXbLE2t10kzWRfhcRRcmXMiUAcE+UH0xSkyaWKku4A3c1aBkrF3gnGpYAaJ7GvVgceg/g yxzmdQfwvKTIkJPUuLEVk8XS05XKLzx/ZMxKwIP3mB26WtbxBg0UCPnSUKQGqDLz5v39BomrfOSR Zjvv7Lhmjs+OBR4r67HHhjjxgHgs9ocfHloAEO8bB5JjjjEjnfknn3irey1Tm9K3s0K7M2OlH8Xa wkyM1R0Wtl8BnEQyCIckTIA25kFJubS3hHCbcn5P79jRGiraVJOzz7akrCwrWU8mxHI1uJkHlQne 1d9E+foUaJdlsvqbIz8fkjr5Ug4JSHYpeneQvbjJmWdaA1EjscL7Z6UcsvOHxLQEPHiP6eHznfcS 8BKIlMBy/WOMqqL5Wyw74Qi+G5WCJdlHA990PUdmyLCNIlW10s6do1ZAy6vmUi7wLrpfgXx6JhK1 RrkrPHTftEFiVDMUiKCTDD/1tONaTMjOWF28b9qt+6PjVAKVCd5j+V0Zp8Pvb9tLoPZJgIko1msA 3Bkd/o71+6mJ/gOAWcSt0K4bVJR1IWWjVeW145IguldNyCrWrymSnOUuXGirhw61RHauYth5MFrV 0/er9krAg/faO7b+zrwEYkYCgaU6lj9LCzuW76W6+r4+BXWLIOhGsWKFhS6lLvu6YRlsbCKqiZ2V mJkYfUe9BDYgAQ/evWp4CXgJ1KgEAD1YW2O9RpI7Yv1eqqP/yIvrrLfgDBrtBUuxFhhFcrKuDnnF 8jXEaN9w8Rb3aNd0378olICPNhOFg+K75CUQTxLI7dbNFlx4oZUo2khCjDp4JgpsFixebPMVJSl/ xQprfvLJVl85DIpwxPNl/fhc473s3Xdt+Wef/c3XAVCfpQhEW33+uSXIKbQmwgmWyXlXHxPUf6g9 K7780oqWL7cE77C63nEmCg9yWvDgg5aryDyRyzKejjYKB9zurrusEM57jD7//hH3EiiPBCqT8+7B e3kk7o/xEvASqDIJFCnKUD6RhWK4uDjvf/5p43v2dHHet3z5ZWt14ok+zvtGxjRZv828+Wabfeut xt9BiRXw7mg9AqZJclyN9HeIYTWukq4D1osUNWjCrrvaaoUTjnTs9eC9SkTuG41SCVQmeI+Bvcko HQXfLS8BL4FKkQDhAAuVprpQ9INCxUWPubpypRVCn9BnYDks5n4knZi7l+qSv8LBIh8X4ztWS0Cb 4V6qS26xdh2eDZ5v7Ua5cJC+eAl4CVSKBDx4rxQx+ka8BLwEKkUCQdSJWPvc0M3H2n1UZ38rRWGi pJHqlFs1XStJtKAU5Srg00WCIbKOdhr4bkM18tjgnMoaIahpKYrsQ/Ux9StLqr6dWJVA1YD3cMKS BFmffPES8BLwEtioBAgJ6IuXgJdAVEmAxFn5OONG8ND5rlAW9PXVAlnY+b0yi0veJV+COvJ9SNWi getynWQtKOqKrsRnZV+zMvvv2/ISqCoJVA3nXQ9akjLOpStLngHg49ibPCG8tVoS/qyqgfTtxp4E AkcukpMkpKVZItxZ6UlcvYygm+y0k+U99JDp7WxCC7E3kAAMZQPN/f13m9S/v2UvWGBbPPGEtTjn HCsgW3CMF3QysHSim0XlTJoUeR7n/E2v1Way9H32VVfZXDn5xiTnPcbHdUPdBxADkq+88kobPny4 /etf/7KrNE5Yvn/66Se7/vrrHahnPCPHlHN69epl999/vzuWf+MXkKjsyUWizUzed19bM3p0uTnv tA1g53OEuPL/93//Z99++63Tvz59+ih595G2q3j0HJOXl+fmTl+8BKJZApXJea988B5IjhU4qa35 jMOHKphIFr/wgq0aOdLq77mnNT3mGCsJxwSOZgXzfaseCbDFvPjVV23hc89Z3R49rM1//mOJmZlO R+KmMD8QpYOt+VgttRC8A5gAYOnp6e4TaydgDKAEuAMs8d3GCucxD1I9eI8d5WaMGdv+WoiO1Lvr ZEVOevHFF90NfPLJJ3bQQQdt8GYA7wBsdASAvzngPWjj4Ycftrvvvttat25teyiCE/375ZdfbJqy 2l566aV2xRVXuMWlWyz44iUQxRKoTPBeNbQZhEecXlmjrF690Ge81YYNLaFBA1umcGdz33jDVshi kaDvTN/FnSzibezLc796LhLq17dspVdfMmqUrZSFywTcDR0pz/m15RjmB1nmfIkeCQRUhQyNy+/a TQA8YX094IAD7KyzzrIPP/zQskV1StNuUeldosAaC83hxx9/tEMOOcROOOEEmz17tobZj3P0jHLZ PYGWQmEBFxQAdbAou+eee+xLhckE0H/66adOLx5UOMiAWlP2FTZ+BPo1depU+1zv0Pbt29sT2s16 ToYOPl966SUH4u+99173u9etzZW2Pz/WJFB14B2Lmqwz8V6TtIjBppiEPMork9zckNyCTy/H2qlH rHG1BbxOP2TtSsCaWZ7xRjdUS8KfMa0rZVhwY21SjfX+As4ATlhQjzvuOLvsssvso48+su+//94G DRrkvoNGsUqRTzguKFg/M7UABbjTxlwtTL/55ht37hrRJz0/ObY0Y0P0Pb5nNwUr+N577+0Wdfvv v78dfPDBjsYCRz6SJ1/Ru2aB2LFjR3vrrbecLtI2Oz6UwHE1V/MfukXxtJmKStqfF4sSqDrwHovS qOw+B1EBQjNLma3zwuMFmKoXIlYFPPr5zpdaLIFAL8qhH8ELihdXXVnes2S1rqeaiTOXdMa/vNav JwH3Grm55yocrcLLa/3ywtK6ZMkSu0uJc8aNG+es7u8qmdI777zjLJ3IEAvoC6IEAsgD0B4Adqzs FHSTggXXRwepPXMYYwk4hxN/1FFH2aGHHup2WM4880ybN2+es4JXht8O12Bx2Lx5c2vUqJGb39A3 FoSnnHKK/am8CpdccokddthhlqOQo5VxzdozSv5OarsEPDKswhEmrm1J4Ny1ERAeTErwQlcqLu6M GTPsjz/+sAVyfIM3yGTpgUYVDlQMNM2LyYF2ASG4nThwYQVly5qtZSxQ/MYxvvwlgQA0rpVT8Jw5 c2zKlCnuE6tepEOll9lfEgCEIy+AGAUe8xFHHOEcBAFsgHp4zwAm5ifA/sSJE+26666zPeXbs9tu u9mNN97o9NKX2ieBwKAELYpFHXQZdlewkKMTlTUH8XwC4JnbgggzXOPYY491+nbbbbfZDTfc4HZ7 PN+99umZv6ONS8CD96rSEL0AizSRFWviQchJ8D3XY10Noovwovz1119tlPjPY8aMsbFjx7pPQBov QSYxb4WvqsGK/naxdvISe+WVV+zoo492W9WnnXaaA1EHHnig+w4wzxYyx1ICbmrpuwucCKP/rjev h9z/cqWt/+2339yzxSfPFZ88V1iVAaneKvx3OaNnbdq0cZZULJ2A9X79+tk5ip4DtxmdA6wB0Pkd esz555/v+M69e/d2IB7rK8dSvOFh8/Q42s4Oog2xkHtZmYSffvppx0N/6qmn5NLVwAH4yhxzDBcA dJ5XLO3sCt10000OuGcR5QnqoC9eAnEmAQ/eq3LAA547LzAiapQqTHAAjJkzZzrQDujaZpttnJc/ XEJehE2bNnVe9VgMKQCNwGkoaC6w3AfgPkhmETmBBt/5BUBVDnjltx2ES+OFeccdd9hJJ51kX3zx hXXo0MH2Veg19ASghOMYYP5mpZvHqsx3cI9Lx0LGSsp3kVzlyu91zbfIM7J06VIX6g6A3rlzZ2cR 3meffdwnXFp+B8zz8ue5CCggkb0Pvq9MMFLz0tl4D9A1rKfnnnuuo8dst912Tk6AMxaKu+yyi91+ ++1OrhxHCL8ffvjBcZIBcgB5ADwLTIqnM0T7iG9a/wI+++GHH24nnniiW+SxsMMizrxTVhSiTbta 6Gh0kncfi8hjFLWNd2RglY+nZ7MisvPn1E4JePBeXeO6nuQVTEY4fQHeARM9FC6wRYsWzpoA8Gqo yCNbbbWVdevWzfWSSRHAMWHCBGdh5XzABRMb4H7WrFluQsMSNllx9jmeY6gAuvHjx9vChQvXhW+r rlv316m4BIJFFw5bjz32mLVr185ef/11GzJkiKPMANr5m1Bqe+21l7OYUhjrf//733afYmjj5IXl CtAOmCViyKsKUYmu1EarcxDakEUv98wiuG3bto6Dzb/rK8oPz9v222/vnrPACQ6qGnztYMcieD55 3lYrXnttlNX6NBOwvXjxYreoYbH48ccfOx3Dynreeec5isItt9ziaBLoEDpIadWq1TrLK/9mweRL 7ZNAAJZ5Jii8w/ibij5UBZhGJzE8YLRAz3hGK8MptvaNjr+jeJGAB+9VOdKRDqulwHtAlwFoMzEB JvgOwB2AqsCBld+wyGMtpS5btsxZwgAdHANIAXhguWeCw/rBgiCw1vOyBYDMnz/f/RZ3iYCqcoyr uG0sm7wU33vvPbcdjfMgFJlIy3njxo3t6quvts8++8yuvfZaB6CaNGnijicqyENKgIRVGZ4o1lR4 qjiAoSu10SoKyGZrHcoMADKwBrLIDXa7+GzWrJntsMMODsxT4G/zzAQLY46hneAZreKhjorm0Tfu G0rCjjvu6DjuLPywvmNlZQG5++67O4MBi0c+AVOBcYHPQDeDRVFU3JjvxCZLIADnGH6CEryfIsd7 kxuuwAnoJb4qOExDz2IuY07zxUsgXiXgwXsVjbxztglz3okzk0is3EgaTTiTJoAasA6QCkA74AGO LgkyqKOVlQ5LKlZ3rPHbbruts4rBk1+hzHV8YqEniQVAHVDCv7GyAz5wfMURFksj53uLRRUNehU0 y0uLxdpXX33lWg+AEn+T7RDQTgVs4cAFF5SFGhb4Rx991NjaxvoOH55j2JF59tlnXXQIgFdt1AUW tFiOeY4AnkHCIe4V2bD7wHMFVQ3+O6AAwM8imQUwO1hBYiGeHyz27IbVRlmVVlnukcUOwB05PPDA A46mAA2GzJpQJAYPHuzkA3UB/SSOOzsaw4YNc1Z45I4xAYu9L7EngSChFgt95gwclVmIsbhlMcyu C7VTp07uu6qwtEdKjfa5DrHeb731VkcN7N69eygJlC9eAnEqAQ/eq2rgAeeyWBCH24H3cMKL0pcD LARe9fwWWN8B3ITCWrRokdvKx3kVEAcQAYADxAHzgDFABzUAYwB4JrquXbs6Z1cWCEx2hNzyXvlV NeBV0y7jjYUJSzklGD9AEzxjLFFU+PDwkAHw7LpQ0BPAF3QseMgAqzvvvNMBeqzytVUXgsg8QUi7 yJHhmeHZYmHL84UTHJZ1njsoNNDW+B1rIzLC+shiOF5ilDOHoBfHH3+8WwhuscUW9sEHHzinVXSH hR87O1jkAe0cu/POOzvdQyfhPeNTANgPLLZ81lZdq5qnvmZbDRxSod0xnxC/HfCOwYj3DOCZyt/V 5SzKdTBO4STNwmHLLbestmvX7GiU/+qBbTBeP8svqdpxpAfvVTmOYdrM+iK8B9ZAQDYlSGLCxMnL EUdEHBJx+urTp497MQZ0Fz6D6CMAeixlkeAiSKLBMVjccSwDmFBqI02iKoewptvmpQl4JJ4yhbTg jCkFHcEaCnA//fTT3XeB83IA9AHwAFIAFBZp6FfBb1VtMasp2fEMcc9YzKHORDpy8yztt99+LqnM wIED3bMWmVSG8zie3SzkzN/QkuLB6h6MF9QIqC8AcKzn+FhAx7rmmmsc7/3999+3//znP25XIwi5 iZX27bfftosuushFoyGxEyCLT3aG0OHqsNLWlM7VxuuycOW9FIxxYFgK+O3oSXXNIVyHBWBwba9L f2mcwxJJCZZRNyWua2KyDKbKhRkvxYP3GhrpII04YAHKDLQYwALWQl6cAHI+AQ1MWIE1BJAeOJ9i jYVCg3UdS2IA8PmENkBqc+gzUC0CJ1fPE6yhAa/gZYPIH9Bc2KYmsgcACRoNeoP1k0Uev5UG7/wb wAXYIqlJy5YtHQceSgM0kNpaeGYA5QBGngGAeLDg5blCboBynisWRwEAARzAf4dyxDnsavEsBQvf 2iqv9d0XwAzdQ6+gTWB1x/oO750FIDIOABRy4/iePXs6UM+xOAnDk2fnB6oDu37VZaWNp3Gq6nv1 xp6qlvDmt58k4J63ttDmTVoeqpNFpY2nyj1PXG65awrcIiZeSoIezjLXKvcO+sqeeGeoDezVxR66 4nBLSpRjZWFRvMioQveZKJCQJ1A9VQ6GawTM24o72FovsWKoNHrxBQUwDa+W7XteloSGBFwEnFs4 7QBxXn68NLGmY30FwBOaDesi3F3oALwwAS0cD6+X39jS5kX7888/u3PhsnLNeLIkVmgAq/oksgWK SjVb4HrWPfdYA9Gatvr6a0vCJ6FU3OIgXT1Oq4AjFmJ8BxClAJwAUujIhRde6KLJMPYvvviinX32 2S4KDU6qxN0++eSTHVf5ySefdBFYOK8cU0BVS6PS22cRDO2F5wrrOw68LFgCihrPD3QyrMdEc2IR HYSjY6eKOPA8RzxT7I7xvGxQTppCk4g3rYXCJMk2W7SbLRT3uoXC5xWEI3JU+g3GeoOB/msxOVc+ GZGuh7xZsiT3rT7/3BK0Y1iiBVZ1l6QkhQ6VDl3zv4/szS9H20kH9rTbzzvQ8t2ipsxXZnV3N3qv h1VY81SR3mOTZWRYI/+tyKDJhep5G82B7bQwLNRzpwcteu8lCnsGequTlWoTvptnL1z+gyXo30kp 8WWTLS4q1q5MiZ10767WY+92lr0men0hsuqm2xNv/Wj3v/K99ene3h679hirnxV6j29qia9R3lTp bM7xejkVacsRp1XWgkmkCteTVnrax2rFtjzb+TgD8W84uHjTw73FEQzOMlYtwAe/YTHkWCyCgIou Xbo4wM9vWBIDDi98VYA61kM4gvxGm5Tq2u7cHBH6c0MSYIwZO7jqWN5JiEJKcPSBCrUK3vubb77p KAosAHF45rg99tjDHn74YbeoI1INx2FRfvzxx12btXUnBiDO4mannXZy/iE8A+xOTZo0aZ1PAKCd mOXsSAQ7WwB0Fj5UZMOnj87kn0QvAS+BqJUAwTEK9Y6Q5Rnrc9zV1bpn1WIB+HjCNR68V9UTicOq rDQlAuOA9wRRYDZUAA5YxXEAInRdkEymb9++jhaDhTTgGwI0sJwS7zZwLgOkAO6xEAI+APMks4BW g1WWBQGWR6zwALuNWhGrSh6+3c2SQJCQhEUbCVFeeOEFF92DSiQZHAgB6gByeKocB5gH7KMPfIcu cO7QoUNdvG50pTY7EgahIXlmoHCwQMZPYM8993SAPggjGcgAaz0gn90uKvQZwLvfpdos1fUnewl4 CVSxBBLEhkhOVQLHOK6JkkE8FQ/eq3K0NxLnvfRlAQiRkUQA5ACJ4PsAQASx3CNXmEF0jYBuwyfH RW7zB5k6+d6X2JQAYwjdAyDOOBJ9gYpvBN9Rg4UZFnn4yuzcANo5N7Au4wMRLAhrI2UmcnSDBUoQ hjXgvHMMz1tk7Hf48SQjIowkMsVfZH0Ra2JTe3yvvQS8BLwEvARqiwQ8eK/KkQS8B6Vs1wJ3JGAD oBGEfSwNrgIQVvr7yIgZwfnrWyDUdrBWlcMZLW0zhgByON3UAJxH9g/94bfSsZCD7+MtgU7kcxXE sY6UF4thFssch6WeHTAWQMGCJ1rG3vfDS8BLwEvAS8BLwIP3KtQBHK2gzYjzYgniz3o3pyoUtm/a S6CCEggWxOxUQD2CC48jqwfuFRSoP81LwEvAS8BLoEolUGXgHZtzamKypSWmuM94q2mKBpKUI/Cu yCGJqWmW1qCRZJGoGj+yYOxTEiJjC/xdl+NeRySOpIREt6jT8i78vMSPfgTzw8Z0pEpnv1KNBztW NZF5NlnPSdzNlbwjirXjoc/SNVURXVITav5ZSCpJtISiBEsqEZ+4CufuYOyZB3zxEvAS8BIoSwJV Bt4BJNnFSqpQnG9riwtUC+OqrioUZaFIYfgIfUVozYRiW6nvQvKIB1kU2Crda14JwcDWX9ARZBE/ Mvlr3NfomVhRlGuFun9e18QhWiv9WFWcEyf6gSxCOpJbEh1hZ4PcCzVBLcuXHiCL+JkrNfbS/5wk xYtPS7L89GTLzwjXtETL099rCuXfUVQzz8Nqzd0rCvV8at4uSRJNLaHQ/XtVUVW8ywrWzYH/jEdW 1is8Bn53ERtioJ++i14CMSSBSo/zzuRTJyndfs9eaBeOf9RWF6xSTGqcJOOLNFKSmWpths2wM275 zDJy823QNfsozm03S8gVmC0n/z2G9Gg9XVWozKK1tlODbez+rc+yZFGHCopDIA0dyZSOTM1ZaBeM f8xW5ZPJEttb/JQS/CGy0myf/31nx7483H7r3MSefOwYy6ubGtKRuCjSEQG0Hg22sge2OUe7NInS kRi8982I887OS4osujf+/pJ9s+gXS0omE3IczJXof6JAu2Lt5ymEJ9Ey1hUZPJLqZllGxw46Rval mpgvoTrqv9lLVtqS1bnWtF6GtW2cFRqZSu+PIpNpIZsoPXhg63Nt5wZbaCGf7a6/qYWuJacmKnRw aD6NBk1KslQrzF5uE3ff1VaNmvSPOO/tb7rS2v3nXisynv3oi/POKBRLsLlrQ47/0VRcnPd6aTZ+ 8Bx77uLv3YDHXZx3hckkzvtpD+5uO+7X3taurv68EOXVicqM814l4L2eXkC/rp5lu/58uULXLZM2 EYQ+upS+vMKu8HEZSdbl18X2wH2/Wd3cIrvmou42on8rszwB2LgQhaa8/FXWp/nO9lXvOxx4x7oY gPcs6chva2Zbn58ut9y8pdKR9AqLOiZPJJuGgPopz062m96eZoPbZ9lZ9+5iJZmiGeVF3wusamQc 0pGdm/eyr3vfKZpEkm69oGouVZWtbgZ4TxZ4T5Vx48hRd9oHcz4Xj6R+nMyV0n/mQRKNKTrW3wAx wB5fIUVPct9HOv5X5Tj+re1w/9IEglP0TBZo3s6Tbjo8vemgusxuy9JvSan2+c53275NdrBVBasr BN5TFCrwzz9W2Liv58rPSvC/RmT397tN0CIN+ujil1+0/DnzLTE5TKWUiKGo1e+/p9VXCNdiOeFX /sKoTMlv/AANdZHe2XUbpdtOh3SwVO0QFQksRkvx4F0LKw/eN6yOm5JhFauqA2arZ9vAETfY0rwV mpSIcR4XiPUvIWamWJ8f5tot949wc/3Nl/eyYbu2Cb0A4kIUuumCNTag6U72wU43rge8Z9q4NXNt wPAbbEnecvfiiqvC+1/g/aynx9qVb062HzrUt4sf6GerpTeWF4PW5woNXkhH+jftYR/udFNcg/cT f3vA3pj3jYBiVhzNlSHC2Hrnw3X4OHxMhfSrsk+qwr7IsIE/1Cc9b7EBjberMHivq928n9+bak+f O8RSREdKVKbYmi+hBVhSvfpaUPzTB4pEhmQeD5UqWBhtjgDUnZzV+damWyO77K39LKtxuuXnRM/8 7MF7/IL3aniy4wKprmd6kMNVfpElsypMTrScdCateJNFee+3vMdtziwcK+fGmyzi7X43pofxJovw /Qac6MjPdWKKJplUZV8qp21agTZRp0GaZdanpkZBVT/qpVqa5VhqoXJUlKrpKUXhvkZLf/8uszqS Y0aW6IzSz2ijzcTKW833s/IlUA3gvfI7HSstlkSZESFW5Ob76SXgJeAl4CXgJeAl4CXgJbB+CXjw XoWaUTm2lCrsoG/aSyAKJFCsrfRExVVPzEwPf/J3jFWZ5RLhbkcBxzgKhtR3wUvAS6A2SKC0AXJj u2Qb3UGTMEr/XhvkU4P34MF7FQpfEcYMv0SKt8JXoaB90zEsAcW3X51tBbNnWf7sufqcHXt1zhzL nzfPCvTpHC198RLwEvASiGEJJAi4FOSl2prlWZa7JkM2iRIrzEuxtcvr/q1mr6irKDwZtnbl378P jsteWUe/p1v2qjr/OLcgP8W160vFJFAl0Wb+7rCKMyKRROJokFhhZqTYgR9Os+sfHWULmmTYVdft YlPl9OKizcRFwRlxtRxWe5bDYZWIRDg1x1HZoMNqcvzoiHxBkhTF45yXJ9vJQ1dEaaC4cuokFndF yyhYutTdR5dHHrGWF16oR2D1RhsIos2EHFa/lsNqvfiaK8sp3lp/mKIskahpcx1W68hhdcTH0+2l K4YqZCQOq567uVm6I/Hlri6wVls2tPOe38vqNEyzAkWPi5ZSFQ6rtFlclGzNO8zXfc+2VYsb2vRR W1iTdovcvxMFuBOTixzwLipQPoYVWVa34WqFuS1UJJ5knZsovSu25JRCK8xPtpU6Py0zRzVPx+i8 REXrkVxnjetki2a0lJ5unsEjXqPNeMt7VT2FUs7EYik5r2K92HFa9cVLwEsgQgJ6RoAWSYrAVJSd Y0WKOlEYq3XtWr24Ci2xSROr07GjpXXoYGRs9cVLwEvASyC2JJBgebKWb7/3CDvt/kftwAvfcVb4 7QaOtDP++4idcs/jduS1L9uR17xsh17+uvU/+TM77IpX3b9PvONJO+PBh+2kO5+0I656xQ659E3b 65RPdc4TdrrOPfqGF+zIq1+xo655yTr1mGJ52XEWIroSFcFb3itRmOuaApEo5N9B70+16x8bbfOb ZtrlN/axmVs0iB+rKrDMW943rF3e8h7ihxestX1TtrDX2p2hJE1K2hPjO3RkVIavn9K8ubLlaBel jKQu3vJeFRNwDLbpLe/ROWhxaXlPUHjMTDvo4rft4Ivesj9GdLP/nnCLHXDeu3bwJW/Z9NFd7aVr z7Wi/CRZ14usqDjRWdl5pR144du24/7DbPTnu9j7Dxwn0J9i7bZRssqHH3KW+mcvvsRmje2s6D3Z jmrDIiEhcfNYGd7yHp2PTmz3itBS7g5KxH3fPAWNbUH43nsJrEcCPBIlxZbbtIGl79DDMrffzjK2 i+2aucMOlrbFFkq2pLwF3vLu1d5LwEsgRiVQUhyiXBULnDsUE/4EcC+Z1dwWzWppi2c3t2Xzmtq8 ye1tzsQOtnppfXfs6qX1bPaEjjZ3cgdbpe9oq7gwyZbNb2ILZ7SyhTNbWs6aTEsQvcaXiknAczkq Jreyz5LepxYUG0mqi5X629NmyhaZPyI+JZCYX2DFa0Q7WZtrRcqqGeu1WBQapY70kWfiU539XXsJ 1EoJBObHzjv9bjd9drndPvhCu+iFO61hyyWO454ua3qSLPAUPtOzciy9bo6zyhfJOTU1Pd/Oefx+ u+vHc+1mnd+93yg5statlbKqjpvy4L3KpJxg6bnKmqf285Vee00dwXhvfK8yafuGvQS8BLwEvAS8 BLwEqlYCRKCZ8MP2Nv67Hjb5523kwKsEVonrceJ1O6vhKmpMkazv00dtaeO+3dEmfL+9rVjYyAF7 XyomAQ/eKyY3f5aXgJeAl4CXgJeAl4CXQFxIIIhbNGdSB3vmwsvs8bOusrduP1XRZBpYSlrBhuNh 60SizOD0+snjR9igK86312/+t80eL8f+jNy4kF1V3GQVg3dCrshpKx5rUrIcNBQySaOWQJD3xCQ0 OL5kwf3KCXHDhUD48a0jCuZmYkdbMvxCnpN41BGejbgu4S25eJwj4vHdsMF75jnwoR3jeiqIlpvX lATgpjhgrhL8u3336Xbi7U/ZKfc+Zifc9rRtP+BXsQQVIhLH1dTQsc6iHra6Jyo0ZGp6nqVn5lqd emsVbnON1WmwxoWILPEJcCo84lUI3jUJFWsAc1ea5ajyGU9V95yYn2eCY5ZUrNimuWviTw7ZGvP8 7A0rJ8C9KE51hGdC8skvybNsiSFPE2VJ+Lu4ek7QkbyN6EiFp7ZYOjEM2JgjkEc8zZP+XiPGW+Nf 4mkEsfTk1ta+JijDJE6nS+c2tSVzmrnY7FjYl8xtZiVFCbbH8V9ZvxO/sN2P/dq69JpE3AEXWGvF gsbunBWLGrooMnDh83JS7c8/2rpakJui76InTn4sj1/VhYrM+dMGfnWaLZ04ROhVa4R4Mihwr8kJ 1n1akfWZXGgLGibYl9unWG46C5o4Ir7nFtiALnvbB0f/n8SRbPlF+e5ZKdF/WcmZNi53kQ348jRb MvEb6YisTvGkI848kWCd5hXalvOKbElWgo3pkmIFcm4uK7xgLE84/+i7Yrz37zjAPjzmPUtNTFUO s7xadXtl3YwLFZmcYSeOutveGHKbQmfqxYYO+BJfEigqsTQlqvvk2PdtQIcBtipnlTYlN10PfJKm SlabOAwVGXpJJzinUyzpRYoSQ3ZVEjMlpykkJBAmyIyK/a1Av8shVTH1ZHEvCCVnUvImviM8JDUl LfTupx0XvWbTVXuDA+tDRVaqzrvRDYVKK5AloVADF0+1QPebnWfj2hfa0weZfdinxHKT9J0s8fEl B+lBUWgbbYOFJTuAJZ70I7jX3Dyb3rzIPtvZbMRWSkfN4qbA60ilTkWx0hgvMxYuytIal89CPD7/ kffsxp2FaxwZd2Ll2YzHfsrSjiPq6mX1LXdNhgwKTEsptmZZlq2Ww+rqZfVCVdb5vLX63SG+Em20 p7nv85V8ycVvF3An4+paZWGlFhXLSFeFfI94GqqqFaPjM0ucsVChG66vlu57eY+BL0MIUxac4Ffa 4dygvQ1dL/KY4JzyXDNaZSzL4sZLDOnI+mRcXr1Z31jyXaAj7JaX1VZZv0erDpTZr7J0JE6mZJ6V MmUV4/NpoMNlzYORcqi1el96LJ2HVJwou7/NqJaALO9Y2lMzRP0VN501JRSY1Iz8f9QgPCT3k6Sk TRzjvnOc9wQH4lMUJpKKFd6vTytn5P1bk7kSJYN2q/DMf6t8F9CzOA4QXvoY/g1AD282uGHJiThO NMa/nQNY29D1aAvn66At2l3f9byDduVo/+a0gj4wluvTG8af3yLfw4xl5LEcg24F+hepM6XHfGM6 Q5s+z8XmjKQ/tyoksDF9Dlwc0P8NzW+R8ynz3YbmXY91q2L0fJteAiEJlN4Iigz/GPxdWlZ+86ha tKeKOO+Z9lvOQhv45Sm2dLz4zFiho3WSFfCpm1bX+rTqY5kpmaKbhrOJyftidf5q+2nuT5aTrzeR vu7auKtt1Wgrd0zARyySM+r0ldNt/J/jneU0LTnN+rbua1mpWaL6/z2KBlxv2sstyLW+bfs6jmNw Pa1PrUApsuetmWej5o1yg9+9RXfrWL/j367HcYuyF9nPc38W9iMRTLXoScUuIrEN2GKAfXDsBxvm vH9xqi0Z/1V068j67l6ib5bVzHo272kpSeIDhvWmWDQgxueXub8IU4dRtRZ9W7TYwro26Or0o6hE HPecJTZ6wWjLzsm2tPQ026X1LtYgtYElJv5zPT10zlDL05b6rm13/du10AXa+nn+z7Zo9aKQ5T7W ioBZ/8797cNjP4xvzvtocd6/uUmGAClWLI5joHdS+dTkVNu97e5WP1WZFfVfoQIX8JmSKA6s/sst yrUhs4ZY3dS61rtlb0tW9BXm02AOnLVylo39c6yb2xKTE90xzTKb/W0+5diZq2baqPmaK2uDwVqG SuaGT47/xHPeo2kOi1fOezSNQRl9iVfOe3yDd4CvwMOWzbe078/83ppkNrG1BWvlL1hi6cnp7mXz 2IjH7MYvbrQVy1fYzYfcbLfseYvlFOY4oM0LBJA+Y8UMu/SzS+2D0R9Y84bNbeg5Q61zw84O/Afg mqCRgLlDXjrEVq1ZZd9f8L2lJ6ZbdoHMUGHrK239ueZPu+LLK+y1n1+zx/71mJ3X+zzLLswWVywE 1HHq+2raV/avV/9luSXqfDS/6GszeNewHbzdwfbeCe/JtaPY6QT6ACBh3G/79jZ78KcHlVmuyI7Z 4Ri7deCtbvHHbxyTW5hrb018y278/MbQIvHcn6xb425/0xnaoxzywiG2Jm+NDb1wqAs7mlMgwQJs tGAA1B/15lH27aRvzULUw9gqHryHHFZrC3jXQrVBnQb2+Smf23bNtnPAPTCKMLeisyxud3tiN9up 7U72wfEfOCdlajCfzl8z3+747g578scnLSFFzv6nf2l7ddjL1hSscXMzQB/AP2j0IDv3nXOFeqXy sb6H7MF7dM5bcQbeI0M3wmEP8Mv6Qjo6CkxEKX1M6d/XN8DBOeU5dkMKEq/gPdanvEp74DP0An1z 7JvW5399rO8Tfe3AQQfar/N/tQt6XWBdm3R1lBmAMxakM945w/o+2tf6PNHHrvziSuvYoKOd2etM t8UEyM5Ky7LvZ35vfR/TMU+pvaf1+Uzoc/is4ZaZnmmZSZn2xPAnrM8joe97P9bbzv/4fGuc0djO 7nW2A+XJJckOzB32ymHW5zEd90xf2+XpXezizy62vEQ5N/nRq7Txr0hDAOkk/XfH93dY30c0xo/3 sZPfPVmOpwV2Vq+z3OKvR4ce9tBBDzng/p8h/7HdHt/NLvjkAluWs8xO2e4U23uLvd1ODPo3ePpg 10agM4w3dfic4ZaRnmEp+u/xYY+v05k+T/exPZ/f04bPGx4CML54CdS0BLTLuqpglXsOdn1mV9v9 6d1t2NxhNmvFLNv/xf1t16d2tQNfOdAWrFxg9dLrud5e+8W1tvvju9tuT+1mF35yodVNqWsP7PuA HbbdYYp0IQ5tUqpNXjLZ+j/T3/o8qedDek+9/fvbawdwr+kx89f3EhB2yVdIx5yVdRSttq5qHctZ k6kQkILwqjmrM9x3QV2rY0i6FIBunFlzV2eGfw+dj8PrBgG3nFjz5NTq2ltVx0WhWRfBxo9GuSTg 4V+EmOatmmcTZk+wCXMn2Mi5I+3P1X86iyrgyhWtwrG4j18w3ibM0XGqbO8CsJ0FXVvGoc1fUVvW LrLxc0LHjZ873sbNGWfj54237NxsOXCwpi1xFnuuN37WeEe9WbBmga3NX+tAH4VjuP6Y+WPWtTNm 9hibvni6+y2qKTPlUr/YP4hxmLZ02jq9GTZnmK3IXeHGsKioyHZps4u1qNPCHhr2kN3y1S02dv5Y e/znx+24d46z8z89376Z/o2lp8ozP6wzTq+kf4HOjJs7ztbmymIZptMAgpzOBDqlT3TGL+RiX5dq xR24aLjFNmXBFBs9Y7T9NvM3Z2lnjvx5zs82ZsYYmzh3ogPlWM+hfY1fNN7GzhhrY+eNtUd/eNRu /f5Wt/M5oNMAZxDhGVueu9x+nfvrumeDeXDe8nle72uF0vibqEkJAM5zBaQ7bDfNDr/qVTvp7ift +Fufs13/NdglaEqvm2P7n/u+HX3Di3b8bc/aSXc9aafc/bht1Wec5SrSDNFoGrVabANO/9iOveV5 O+nOJ+2Iq1+x1t1mrRfAlyhUZFFhsm2z+xj71/Uv2pFXvWLtt5/qFgPembX8muDBu2TFy2ZN/hpn 8Z5wvYDRVeNt4mUT7eAtD7a5q+ZaUWKIhwqIx/r+0akf2bjrxtnEaybaxyd97KgzAP/k1OR1LxrO nXTdJJt45USbdMUk+/2K323i5ROtd8fetjZ7rQPlN+x5g427YZwNv2S4/XLuLzboiEHuZfbmhDed EheUFFiTjCY27NxhNuG6CTb1yqk2+JzB1rpe65CTrC81KgHGqlBJVf67339t3I1anF093kafN9pR pj76/SNNRgXWKLORG+tXx7waclCtoyrr5A9//GCPf/e4zVo8y3GE0b/Duh1mk679u85Mvnyy7dJh F6cz+SX5dn2/6238jeOdTk25coqd3PPkkJOzL14C0SQBjG7pocpCNkmZluukSfn5jl0i0hnoPxat Ganie/F9pqreSG/89oYtzF7o6DbMg1DGerXqZTwLE6+aaFOvmmovHPuCJSfrQfL5XqJp1H1fYkwC EF+wem+921g79b5Hbb9z3xOoHm29D/3egfTmnedZmiLO7H/+uzbwjI+s10E/2jZ7jLFt+4+2xm0W ydqeYZ12nGKnPfA/B8T7n/yZbT9whO13zvt26j2PWbMOC5yFPbDQY41v2HKJnXb/I3baf/9ne//7 I9tXx3baYYoVKoETM4Iv5ZOAB++8R8ShxLl05vKZ9s3Ub+zb6d/a51M/dw6Fbeq1sat3v9qS0pSI QNlAeeGMmDvCBk8d7GgOn0791Fnoj9/2eNt/m/2tIF9JCmRR4rvgGI7Dwkq7S3OWKh+RyBZ6mU1a NMl+nPajtc5qbTs038G9yKDOPDz4YfdyS05Kdpb+H2f96Nr6aupXNmz2MMstFlrzI1c+Da/Co9Ab fBkmLJ5gg/8Y7KhSz4963k774DS7/qvrHbBgsUeCqoYZDf/qCTMm4wfAAcSIx8tYz181f53+BTqD 3izJXRLSGf33x5I/3LXc79O+cYvGqPZ7qEL5+6ZrkQSCd7aejQYZDUIURVI26nt0f3nOchsyfYgN nhaaB8cuGOt3H2vR8PtbqRkJFInukll/re2mTKlN2y+0Gb91sTsOucduP+g++/TRIxXHvb4L+1iU L8OkLOZPnneFXb7TC3ZDv0fth9f3sSZtF9lhV7zmrPaTf9zOHjr5Rp1/rw268nwb/WVv+YOFQk5S XMImYr/rfwunt7bPnzjcFs9u7n4jqdPm8N5rRno1e1UPAR1+kvVHnOP3J75vFz17kV340oV2+vOn 28EvH2x/LPvDBnYcaHVS6jjAnV+cb1d8eIVd/OzFdsFLF9hhTx9m1351rTWr08x6teyl1MElLnrN D7N/sPOfP98uePECO/+l8+28l86z818+36bNm2YZGRmOx/nm+Dft3JfOtUNfPdSGzRvmHBkP3/pw a1y/sQN+RDFZmbfSLv34UrvwjQvt3HfPtes+vc6W5i0NRWfxpUYlAHDHAe/pkU/bxa9dbOe9c55d /N7FNmjYoJDjqXZrFmcvduN4QZ8LrE6WLI/LQoD+yj2vtDePlY9Fxz5uRweaAOD/guelL4PO/5vO TJ031dLT053+vTHuDbvotYvs/HfOd856AHjPd69RNfAX3wwJYAyBFmaE1F0VAuqn7XiaNUxv6PxC KMzNzMNnv3u2XfDWBU7vH/xOzuBMkv4NthnS96fGuwSSBKzhr88YJb8+lRad5tmR175srbaYY+/f f7zNHNPF0jJzXVZUbE6NWi2xlvqteYc/Lb1OjnXpPckBd6g3P7w5wMZ8ubPaq2O/vL+HffjgsbZs fhNRZ5TcScmc1pC8SZb3pfOb2v/dc6J9+fQh4tKzFe1LRSTgpz63IgxFLxjYZaBdfPDFdsmBl9iF e11o1+1xnW3bdFubs3qOIrgp8YCs82mJaXbJHpfYRQdfZBfvd7Fd1u8yO6f3OU72C9YusISkEOd9 59Y72yUHXWIXH6D29r/ELt3/Urtkv0usdZPWSjpa5Cy2DTNljdXO8MjpI+20d0+zEfNH2LHbHmt3 7XeXpSakWlJJkgP0WRlZoUgiVO+YWBE9r5JzXIg7/Vc/vf5f48MYQQEgCpBcF77840sbMW+EHdL1 EHvjX2/Ypf0utUGHD7J7977Xjt7maOtQv4Pb0WERsEvbXZzOXHKAalhn0Ju2TdrKMkEWJ3PO0Ot0 gWuxiPNxdatkfH2jlSMBFqYA8CB6kmuVpC/SeRakJ21/kl008CK7dI9L7YV/vWCX97ncZq6YaW+P e9v5B0GfYR7E6LFO9zfsC1c5nfateAnEgQQSk0JW8VGf97HhH+7mkiz1PXKInfvkfXbq/Y9avaYr HO2luChJflfFdtwtz9n1H15ll712i/XY9xdr1GKpePH5DpSTkCkjK3sdTz5VSZky6mbbnid8KdrN /9n+5/2f7XHcVw70k7Apo162a9OXiknAg3fJjegg4xaNs1b1W9klewk47XqJXd7/cjtk60OMGNvX f3m95ebn2vK85c7J9PDuh9ul/QXGdxc43/Nia1G3hT0y/BF7e+zbUv4kG7dwnKWlCOTvqbZ2C7XH 58W7XmydmnayldkrnSWJrWAHvgTgJ8+dbNd9dZ3rR//2/a3/Nv1t2sppNmXplFC88CCWsaeEVUzT K/ssjQfW9anLptrqPFnZ1zc+Au847p3x7hkuLOR2zbeziwdcbLt12M1G/TnKLvj0Avtw0oeWlppm kxdPtoyUjPXrTONOtipnlU1fMd3Fh3cLA/TA60Jlj6pvrzIlENZR/IamLZd1LtLJXs8Ljt3Tlk2z fl36ufn04n4XW7+O/ezLaV/aie+eaL/M+MWSkpNszso5Dsw7fffzYGWOkG8rziWA3Ycsqn9Oa2Uv XH6hPXLqDTbk5f3kr5VifY/61jmwpteV5V3gnbCO3ww6wF65/hx787ZT7Y+RWwm0pzmrO9SYwoIk y1ub5o4F8K9eVt9SMgpst2O+sb1O/dTVXY8eLEt+nuPZuzCRYcMTbWDd96X8EojvOO9hOcFJbpbW zFFZIguOrKvyVrmXDICpXlo9a5jSMGRBigBOgP+FuQutsLDQgfemqU0dDSKycA4vrwU5C5xTaov0 FrayYKULq+baCisx/aifVt9WFGrFW5BndZPr2qK8Rc4xMuZKbY7zrvHKSMqwJmlNbFn+MltbqK3/ DYFpORcTUaZpRlO3w4NerS5YHaIFwOkVQHE6kySdiWgjUmc4p2VGS1uev/wvnYk5hVhPh32c99oV 5730EOs5aZLeRDaKZFuYt3Adj535LjM505qkNvlbYjL0fFnuMluTKx4N0eO0K9o0rWkoGpPmQbcA qI3Fx3mPzlGt5XHeAdppsoR33vF3I9zjqM93tkxZxM9/5i7bqu94+33YNo6bfvLdT1j9ZsvtvmNv s7Hf7GR1Guj51KPYQg6tFw+6Xc6ri+3HNwbaZ08ebisXNbR220y3hrLKzxrfybWLFZ5SVJjkaDVQ aIhkc93711jbbWbYazeeaV8+c4i7BlSe9cWV35CC+Djv0fnoVEuvSCQyf/V8Z92JrLNXzrYVeQLu RG4UeF+Vu8rI/jdz5d+Pm7d6nktGwnEAc+gzpdvCYs93ZBfECXXOqjm2Kj8M3LnLMGgjrNofS/+w xWsWu4UD/XJt+xJdEtB45RTluHEk+cxGreBaEzLuHIseoEMOuGNBJ2BGoDOl9CpSZ/C14Ly/6Ux0 ScT3xkvgnxLQc7Jk7RI3J/7N8q7vCa87e9Xsf8y5JGNa58ytswi7u3CtgH9tBe5eb7wEakgChXJE TU1XNBlRWs5/5m678s0b7d+PPGhb9JpsOasybfCLBzigXbfRKktMKra6DZRksGGoAvKXzmtqnz5x hGWvqOucXi995T92zhP32XlP32NHXfuSjllrS+Y0d9x3uO5L5KAKb/40UXLOeeJ+8efnujvvf8pn dqauy29Y7X3M97IVwu9TBMAZgL6+GjiGYvAJ85jXexySDIxCnLOh9gK6A7+Xlj6/cS4bAFwruJ6n R5StyTVxBOOyvnFcX19K6w7jHLHj4sa9IjpTE/ftr+klsCkSQLfX52DP/Lc+nS+dNXpD529KH/yx XgJeAv+QQIqA+6rFDe29+06wkR/3ddbwLAH1377pKXrM2Tbq0z4OTP/2dU8bO7inrV5SXyFaFXVP NJcE8dWTxZEf+tYAG3TNeTbykz62bF4TB9hnjtnC3rnrZPtzahsH/OG4Q89JVvuJSSXuGvWbLrcp v2xt44f0sLUC//WbrXDRaAgy5TmhZSurB+9ly8gf4SXgJeAl4CXgJeAl4CVQqyQgVprjq/8xfGt7 4coL7MGTbrb/nnCLPXfpRfbbV71Ej1ltqxQuctAVF9rTF1xmfyrEY6o460Hh3HRFo5nwXQ97Qcc8 ctoN7nxCSv72dS9HgVkXAlKgHAC/ZHYze/riS+3+4261x8++WsdeqRCTN9mT51/hLPRw4v0mW9lq 5sF72TLyR3gJeAl4CXgJeAl4CXgJ1DoJAK6JGJOcKp89WdWp/J2cXuAs4fyeFP4tMaFUdBhSMcgC D/Um8nyOx8ru4rqXKnwHqA+uFfnpY72XX72qFrzL+chlwPM1fmVQXEYKRK8j8asbwbxQlo6Ufz6L 7SORg58r41gG8m0KcQZ88RKodgkQthFeu6v6OxJIB79tzLdrY+eXvpm/HRtxzWq/6Ri+YBVGm/nT Bn59pi2dOoxUoTEsIt/1Cksgt8AGdOpvHxz+mssySqx8Co5nWYo0MS5noQ345kxb8sdPXkcqLOQY PzGvwPp32NM+PPx1Ja9KsbywjsT4XZW7+8mKdZ6qyFQnjrrH3vjpfqUa1KmKbe5LnEmgqNjSklPt kyPesgFt93TBEYi0s6mlTlaajfh4ur10xVBZQhWbW3lHfNkMCdTyaDObIZmoOTVeo81UEXivY7+t nmUDR9yobKBE1SCbjLcoRI22V0tHNOsVrrIBTXrZBzvdKPCeoOy0oag568D7mrk2YPgNtoSMsV5H qmVUousi0hGFSu3fZEf7sOfNSkym+MCKxBRPxYF3LVpOHPtfe2Pu13LgVBIuX+JMAnoOivNcAsBP 9BwMaLydwsGu/ntSq3JKxIP3cgqqvId58F5eSdXYcfEK3quQNhMOq6IXsohPvsalDMJjv9HHmpj5 HMen15P4k4HGPrEKp6Eae6VsyoXDyUqc/vv5Mv6egYg5cFPUJgqPLS5KtGLF8g7idPNvYnsTT9xV 97eOCR+37vvSvythz1/HJ4XbiPd5IgoH3HepxiRQxU+DrO1wmn2NTxkUh8d+o+rtdcQ/H35XLrQl 5efKuJdBjUGBzbsw/GgAe2FBsquEEqQU6e9iZd4knnhRvj4F3vmOYwD1fB9Z+c7V4HuO03nFfKq6 4plAmzdY/uxaIYEqBu+1Qkb+JrwEvAS8BLwEvAS8BNYrgRLLz0118b2P/8+zdvZj91ubrWa5EITH 3PS8nf34A3b+s3fZhS/caRc9f6cdd+uzdvKdT+rfd9gFz92l3+9351zwnH7Xd8fe/LwddsXrdtaj D9h5T90TOu/F2+3EO55yUUoK8wTiPYD3uhjnEvDgPc4VwN++l4CXgJeAl4CXQIUlAGVf1vKU1ALb fuBI227Ar1av6QoB7WLrse9w677Xr5bVeJVlr860grxUy1ubbrlU/TutTq5tp985h/OzldUzZ02m deoxxbXVbtsZOjZD56VogZC2jo7jXegqPFr+xFoiAQ/ea8lA+tvwEvAS8BLwEvASqBEJ4LYh2gxA mwL1BYAN4Ka8c8fJdtsB99u9/7rN3vjPGfbWnacqIdBN9tatp9na5XWd5f7VG86yB47/j71126m2 eE4zd97wD3e32w+5x+487G578arzHFeeLKC+eAnEuwQ8eI93DfD37yXgJeAl4CXgJVAFEigWoKdg Rd/v3Pds4BkfW4ftplqS4oinKTNnijJuQoHhqJSMfEuvk6OEP/n6d8gPpvVWM23fsz60fVR77PeL OxArvy9eAvEuAQ/e410D/P17CXgJeAl4CXgJVIEESopC4L3fyZ/bvx962E4S133r3cdYfk6aSwIU mQgo+Ldzfg2T2rfcZYKd/sD/7JS7H7e9//2hUiAUO6dXz3mvgsHyTcaUBGIDvLN6V+goV8Mr+aiV 8ob6Gnwf7f0vSNFeZ2pI1r54CXgJeAl4CXgJVFACZOukvC0qzPX9HrPbD7rPhv1fP2dh3xAAx+Ye gPpRn+1st4puc/vB99kbt5xhxYpik5xKJtoKdqgyTuPa0VQr455qUxvRNDal+1KJco5+hCYQSYCo BsmFVof0vVqVR3NJUf/qqa9ZScpzDlAPg3W+r6/v08rbf0JtAaSp1QH4Jec0yfeirlPsnu3HWPf6 K0Rc9NuT0axrvm9eAl4CXgLRLIEAhK9Y2Mj+nNrGFs5o5RxSiUTjikPqf4H10veyZnl9mzW+k82Z 0MEWzWrhDo601lfLvauPpCFJzVBCtZQkS60bXTXJ9F9qghUVF1lRkSqf8VS5Z1VkkChZRNv4RPaH PB4lKSWWawVWKIyYLJ2qaKnCDKuzlWH1BmVYXa7smenhp3QTuylA2TClwG7fZoLt0XiJLReQ/c+k bvbNny31JEU4rUSAZHcFgdB1pQRrffhfAOcAPJc+Z2O//a29vwC5a6tUe9duNdkOb/mnnHfMnp3Z 0Z6d0dFKBIIPaTPXbuw20T5d2Nzu/n0ry8GyzbmRFu6gPfUtS0C/e901VqC/f11VzyWsWHe90vcQ cZ4D+qX/HQhjfffId5yj9rPSc+3nfkNsm7qr7aRfe9or0zuZqR+uRJ5brmFk8bHaBjTtWY4Mq2Th DTk2+RJPEgjpSP+myrC6001xnGE11U787QF7Yx4ZVutVbK6MJ7WpjfeqzMJpyrT7Sc9bYi/Dqt4N eWsyrGn7BXblmzdZ3Uar7KnzL7dpo7a0Gz66yuo1WWErFjaUY2qWJaUU2eplWfb+/SfYhO93sB77 DHdhJJNTCu2eI++wqSO3stTMPEex6bHvL3JY3c1euPICS4MHjxW/um13mqLysgutWfv6dvzNu1md eqlWIKAYTSU1KcWmj1loHz442oknKbnigDCa7qu8fSHDanFRiR10yQ62Ra+WVlAYnQ7Nzq8jKdXe G/KbvfbFKOvepaVdcdJAq5ueLrxYXsVOsAbN6lhqw2JBsnKcde+gr+yJd4bawF5d7KErDpezSYIE tH4Fhq2WlVzHfltdCeBd9I3jOk23l3f61XB8SRHf7ZFpne3ycduZg5QB+BVAT9NvSfp3Poki3KgD SrUOk8T4DdGsA8zu5wRLx5KvPwv1N+c50E+bArJYylOZlGjP/cb9amUni3h6IncZ0R7n6ZgEAfE3 dxlm/2o1z/VgTk6G7ftzX5ukxcZZAu5P7TjK3l/Qwk4Z0Vvpr0VNUSvJ4ev81Z6+lkf9/q3n2Ru9 httiyWDv7/a0+WvrWoKANH0p5HouCUaCZej8XHerJZao34DARcghTDHiPqi0n0fWOu6FFZ/+nazz 89RUCk3pmmlp+fb17j9Y7wbL7diRvexNgfc0LZ5Sdb28sGzL+0A5c4oH7+UXV1we6cF7srKqpiZ6 8B6X6h9507EM3nl9KIFShuK873zoDy7e+8hP+tryBY1tlyOGWD2FicTSDoUGq3nu6gwbod///KOt Ne8433Y6YJh+LxSdZk+d00Tgs9C2HzDS2m4zw2aO7WzjBvd03yXoHVcTpVjJBtNS061d886WlCTL KckHo6k4Y57wh3AZGJBdgngsJcVh/agZNSmfyMNjwxglJSZZekaGG7fyLkoThN86bN3Suh6TFMXg XZ1MFth8eIdRdmTr+Xb771vaTVv9bmsLE22/n3az31fUF/ossnoCoqd3nGEHN19gdfWAY52/XZbt H2Xh7i8L+Pkdp1nr9DxnXH57Xmt79I8trIkszJdtMcV6NlhhKZoQsuUA8+78VvbyrA76O9lOVnvH tZ5r9QVcV+vft01WewtaWvcmS+zKLlOsY51s0Xdor5U9Pb2zZYdpLYD3l3v9Yse1mWdzBdzbZWbb 3bretbJin9J5mg0SGH9dfThT/84uTLGj286yk9vNsXq6DqB64uq6dvfkbpau+3ij9y+2Q71VTiHG rGhgi/KB5SU2JzfDLh7dQ9tESXZT93G2c8Pl9uys9va6gPax6vdZHWbaV4ub2v3q84kdZtkxrefo PgrdQz0jO9PunbKl/baomR3feaqdrmNZYHTMXGvLtJi4S7/dpV2OAU0W2z4/7Wp5AvT/6TbZyeD6 iVvbOPUD4F++4sF7+eQUz0d58O7Bezzrf8S9xzh4B5QTxhFKDNlV0+vmCOgWWY5iuRe7Xea/7hXq a6riuyfrvQfoz12b6cBLet1sl4QJZ9W8tWnKvJqqsJD5LioNYShrqhTmFVr9ZnVtrxN6qi8p6ld5 34HV1+MEocGk5JqTUfXd6YavVCTr+zoAHw0d2kAfMH4nJWJILRG9qfy7SUnpibZkco4lL2pq3f+d EsXgXQ9u72aL7Mu+Q23C6iw7asTO9uR2Y+wQAfJzx+xgTwk0lwhUXiKL9oMCsSsFht+b08Z21zmj BDLvmtLV3uk93DrVWWuf/NlKFu5i26r+SlmUe9txrebaRQLTPyxtbGOWN7Lj2s1yNJVjZRGfJIrK kD2+c9z0lwSK99Ki4Pc1WXb+qJ3s3u1+s1PazbbXZ7e31KRC27HRcjt9ZE8bIjDsQK0mqVcB723n 2pOizGwp+sl29Vbant/3s+5Zq+yNnX9x4P3kYX1s9+YL7YNdfjbW8K+pvY511th++u7NeW3sZlGD bu02yY5SP3OKk+xDLSxYlPxLC4rGmsx2/XYvd/2vdvvRWcVf1vknD93VHlV75wvA3zZlKxuxvIG9 2WuEu+9XZrdTX9ZY38ZLbYLu5ZAfdrPDRON5QHKjjF5Z377S4uQlFje6x120ILhLi459JUsWOJeM 626DJO+cTaLOePAexfNHlHTNg3cP3qNEFWu6GzEO3mtafFV2fU1RuavzFbKysV3yygFWt366FRZF m+Xd2fV8QQKsX6JZFpvRv+SkRJv09RKb+k6x7XBWmmONRGEJrSC3F9jG+j0vJ90yE4ps+IqG7vuT 2s8Wd6jIWgqYHysQSrlBluHTftnF9hTF5L4/utq/9D3AHY75Mb/0tgNkST5GoLlNeo4d2Wq+Owc+ fRcBbAAwzprdBLAbpeZZprb3EqHGqBv3qi046mzrtZTFnlI/Nd++XNzMLtQiYuKauv+wRtP7cVoE PDRVVn5x88/uON2yw1IuEMCvp3ZOajvbLRiKdBH62SJN8W5VdhO3f8baOvbfqV1E2Um0pVrEnD16 Rztf9/bZohZuwA5tO8e61Av1m8I9HC560a6Nltl0Wdc/XdjMTlX7GaL63KEdi9NF3Tngxz1ssCzy 8NkPkGxWhZ1Rf1rWyA6WbK7+dSebrntJg1Kjdq/Z4g/rq/bYOXhCMlBsgL/4/VGoMb5LXgJeAl4C XgJeApUtARcwRFbS/Nwi1UIryImyKk5+vvrkq8ZFsoi68YnUl80ZqwI5ubLrE1BvopLzXpRsLTNy 7J1dfrK+sgJTHO9cBY74svwU21+Ac62O+0SW+eYCvgN/3N2Gik/uHEAFil+RFfoEgVTA6w3iyMN/ N5133Ja/24s7/irQbPbt0qa2WOmas9UO7X84v6WzQB8kvvkpAr8HycoPjeY5WeCvVxvtslbbmaKa nNBmjrUSAP9OlvtLxm5vY5drURFheT9elvcbJ21td47f1j7e8zvbQlb1d2Q9BxDT1i2Tt7Tndxxt ezddbL8J5E9QzRWYhpM+KyfT7lef95IV/mPdw8K8NOvxzUBbKuv4xdv/Zg9uO87Graxnf+alW8+G K2y57qmOrs15OzdcZh9JBpfrum/J6r6taDeHDdvFPtU1kctTfX9ytJprtdBZpkXBUzuM0U5AGzt5 eG9ZE5LkOJFrX+w61HqJ856jfxM15wk53J6nXQfnC1BuyoxD+p7zXtlvkVrXnre81zrLe2Q4X+aM SGf/ytTfIPRu0OYmzU2V2ZFKastb3itJkJXfTGFBkWU1rGO77NddjrOpijMfZbQZeO5y7ktOjVJb bOUPyT9aBB0W5Mu3EWAXxewh6MvJcihOkRUdiv6m7OIQTWfl7Hyrk9PCtv13NHLe3aScYKeKr/1M j1E2TVbox+WkulSc7CJx6o4TbQXqzAuigpz3ay97QTzyYwWmX53bxq4Z08P2EfBuJev6IsCpwO4s cbpP/GVnRW1JtKNFjxm6rLHd2PV30VlW2dmynL88o7P1l4PpfqKIvCXaCJndDmi20IYsaWq7Nllq N2852WbKmn3Qz33sQFFoAM1rRWW5X9xwuOKnir/+ovpnssYDkF8L02ZulbX+ZrXfu8UCR49prN9x HH15Tls7R1buK7ecYreI8vOZKDenCDyniJd+hvqH4+y9OndvnfeJzlsk8H6qwPNsWcXhoL8vcL29 +l6oa32uc0etbCCqzHS3Q8HC5gYtGv47aSu7t8cYu0Df0/4Zcj7FCfWZniOtqfpxiAB964xce0Ih Id+dLxrPiF6WLVoO4P0bUXEA/a/Mbmt7NV3k/AUu1MLlBYH4Yk+b+fukAVBhByOSjxkscsoCLZxX Om8B5xLdJ2iXNoJoP1xDC0l3Lb4L2qcdauSx1TBZVs4lPHivbeAdQwIhceE1r5VeQvdzels6b0QA 7APQHanf65SL50FAiWM095mMLCELTpF2CAutseY8uNYYPTDoyB2yctSyJlrx4L0mpF6ua+Kwmq6I IF06biGefrK4/dFFmwG4F+XJv2BNOMpKDD8G5RqQ0ge5rRH5TGSlWHJaogB8hVqplpMSxXfPzi2w nDzhweRkq1c3wwWAKUfcmHBU1UTruGUr63qUkpxFneUdC7Am5Y9lUd9THO0bxP++Q7QRB1j0Ejh7 6wn2pCzG8wVq9xg80DqJBvJszxHWTpb65QLsDQVO/zetk90t3vfjPUbboS2wnit6jGgwUxSx5XAB 14GyeN8tCza0laVqp4ks93PlCHq8QCx6ANiuo5fDKr14mohjfr/48w8JoD+p9g4WqAbAt0zLtV/F rT9D4P23wJFTL5F3de4RouXAub/utx2cxfo+9feKLn845Xhlbms7dfgutkXWGufcCqd8hRYmpIvO 0jWxdF+o85qpT6/qvvqrr+jiw6KvXC7Q/8KuPzlKDOVEXfsrWfR/Gfi1dcjItuXi/e/7w+42Qtb3 XbSIeV6Ln27aLcDK3khy4SX3sLjrN2pRcbkWDndqAfLRwhZ2rGQCeCdU5E97DrFtdc7houmkShqv i6dPuMojsODLSm8am/KVWm55J4ypxmgX7XagR8nhSAhLtZPz49ImtpZEVwHwjhRY2GLYTrsxjA3U LWhK7HQskl6xE4Oj87aicE1cXS+0qyMdytJxu4tSlS4g8+2i5k7XAeyd5cuwo3ToT1HLftJOkAMw LvpALBQP3msVeBeAvkyhcq9UrogM6SlBAM6QH9G22j3tJoMAmCJVPjgYUlZqvmEHcZ7mZPS4ruan vnqWMEIwV1M4Zqh0eoWMJw31TOymgAGUIYre1UOUPnZmE9UqPlFHywCyULuPm7Y7GEXPSG0C79jf FFiiiEyo4UKkGeeMKsNcoTNC/F32yQohGYSC5JgiHRNEz3OROWTcqvb47nRR184TKG7RRe/6h/tZ nfppsvCGwydHgfogxoz0NJv883x7/cafncySU+LLAl+kUJHUY27dxbrv2cZyc2RIjcYiXcpQ1KKX PvnFnnz3Z9upW1u74/xDrIEAfFEQKacc/a5TL8VKXOTwckD+ag0VSbhDcbUPbblAiZkK7BtZwKdp cnaTsn5rL2t3f1nEcSj9bmkjmywe/E6a1HdSUqE0TRAAVagjq2Rxby5gs4+sx0RbQTZDBKomCgzB XwcUbyGueQphEAWchqmdEFAqtt3VHgAW69EigbFPRKXJVrsd9AIC+MMlzxV4G0zfBLYiraP9dO6W Ambw83EExeJUD2u3dgsydd4YHT9SvxVrcuqo9vZotFTgDw97s3m56faVLOVrmfT0gttGnH9453Db WSgM04ush16EAH6O/0R8/j+zM+ygVn9aay0mFioiTej8kIV2SwFAnFTrSi7QguDDfy1P5SKB/B30 /c6yxv+RXce+W9JEysNWTpF2FxY66zxtz9eux+GiHuEn8IN2LMYE9KByKFitp80IWPSTrD7Z9UeN a7Fb6OEvgO8EoOUqLcCmSwdLg4lE6drBWljdstUk20HjS0jP1RrvRvKNANycNmpH7Yrk2O1yWB4m eR8rUDJL+rKbFo2D5UjN7s2digp0s6hPhVp43qzdJdpivI4QlcxNW2VZ/cs1ftVxkAfvtQq8Sx/v 3WG0A+/3SUc/1zyMn83T2vE7s/1MKxAoW6W5J9glHC79vmZ8d/tWu3/bap7+Ws8SFMhVmr8I+4sV H72+QEaKxvr+x/6D3fd7DulnU+V4f7ieo39rd7G9gP2O3/YPLQTWt2CuDlXe3GvUEvAO0M7PTXGh ITOzsl14R8B4XrZiWeszMbnYRZDhe2cgDhsaCnLYWU+yQkWfITpNZt21ooHA71VEDn2XvSpT4F++ aOzEVKdtQp3MXV1grbZqaBe9PNDqNAC8R49pF1FkpqbZuO9n21PnfutkkxRn4J0474WFJXbmY3va jgM7Wk5+yH8w6grgPSXdHn/nO7v7xSG26/Yd7Jkbjndx3itSog+8B3cRZBaNpAjwG9uvgFNK8Fvp bdng+4BSELQZUAvWt0UbSTsondW0rPYiJR/0hcVGsCUc2efI65TuX2nKReTvtEU/6FuwBY0VXIsN I2Z8QN1w34VnN85nIRBso0W2vyG6RWm5Y+GNlHW5tayWW94lpwGiUREXH7Bxgpyh8Y94SP4U3bUo e05hR89VSE92LUJgWmOicSJ+/yAdA43qA0VBem5mB5uiRV4/7RAR3ecV0aqI7f9xn5+dz8Fhw3e2 j0URu1sUp6sFiigsCvvJxyNPu0WDdv7ZjtEC62JRmwiDWhLkKij3ONXkgR681zbwfrd2Ga8WLbHb F/vZZBkFTAvRF7SDeKrojlAb75Sedpfh4IwOM2xv6ftMWcsHCIwzV47a6xuF+y2yY0VznCea4H1a COyqY1+Y3cGFw/1YlvZMHbe3dP8HEvXpeXusz092mEIJ9xJ4x9hQa8B7/moid2/yw1mnXpqN+Hi6 vXTFUIHfJMVW3/Q2NvmiEScU5KZaZv01tv95/2db7zZWWUnznQV+xm+d7c1bT7embRfZCbc/5b53 sd/Dhob37j3Bhr69l9Vrutx2P/Zr633oj0qItCZk+V6bboNfPMB++XB3R2vFil9tJQDvWza0857f y+o0FHjPiSLwrtcKuwHjB8+x5y7+Pq7B+2kP7m477tfe1q6KUvAupc3KSrcn3vrR7n/le+vTvb09 du0xVj9LRr4KlOjdXwGEwiMvbUXk33wf+RugNvgu8nsAb+T3kdlCg/aD3yMtNqV/C/qwofYiBR/0 JdKBKrLPkdcp3R7XjbzfyN/DOw/u5RT0OZycwVFZ/vZduEOcIyvHut8i2w/aLm2pKi330rKugJLV 1lN4hVCztZj6VYB6sCIEvTynnbvdjrIcJbKwkjXSWAAJaKdK1qcqtj+UqPe1m3OcqEmfy89ivnZc Xp/Ryc4RUIeaNFp+DFMEXrAyNgkvxvoIxLAkIzoRVJs0/WNb0Wj2l0Uev463BYxcLOSYoczUVq2I 7/sKqA5QHwOKHTpLWaKdwYnaeXxTFMR/y4+HsLXQ/Q4QzTBFu5LsgLITNVbH/Cz64POqlPaZa0Qt U6QP/UZbLtEc86Seo1Q3L9YCmYfvIVmxnC09ocIp3kkPX1OOi1Bd0hS//aCL3rb+J3/urOtfPH2I S7S01S4TXPKmFPlQtek2y5q2W2hjv9nJhry8n0B7f/tzahudm2OHXPK2HXnNK9a662ybNb6zS/aU kibK4LFfWQMB+8I8Ga+qdz3yT+Xi+tFUa4H6V+otRNPYlO5LJd5o9IL3SrxJ35SXQFVJADCRISBB 5KATu49V/oCp7lJfLGgux70iG9ByvpyP/3RW+kPkGL2l6FiU0cvrW4aoTs/sPMxGDPzSvpPV8eN+ 39rhslDmCMx/J0oWZYDoBNuLWkV0ox9FE/tY7eJsfIgSgTXTdzgHzhN4hzNf4y+1qhKyb7dWSMCF tg0bBwhV+zt0SJXtRd/LkpEAcE4W7T1FPTx864ly6p/sfv9WYXnXiE8PxbE24PT1Dmb4Tbzkjxxb OHqt/Tl2jc2vSJ0gH6eZeaGsjdUMcknSBABv3ulPd4uLZze3MV/2tkFXXGD3H3erLZ3X1FLTQ3zk VUvr28ePHG0vX3uuvfGff9v00V1ty50nOJBOeeOWM+zpCy+z9+47wR4+9QZ3XPbKOpacrkVhrVWC WvGY+5uoJgl48F5NgvaXqZ0SAHAAoB8TFeZpheesJ8B+j+gr/5OjdW854L2t6EDviALzrqL4XKUw pWvCETPqyEFrLQ558lH4WvH7mzrn1+XWFXAvS/3bos8QraOPfB4uV4jR1kQCEoj5VM6qAJzDtCDY U5Z3aDlvy1oP596UC8EXL4Gol4CeGSz0WfJpomRLz/G5YSFMxKz/ahH8kha1bTNz7HFZ3x9R6FxT hC/Ae60tKXLSlEyGP7vAvrx+pn32n9n2+S2bXj+5eaaNeXexeM8i3VQzeIfLvmxuMxv+4W6Op77N HqJQvXO9HXX9i5YnTvvKRQ2dNb5Y452RtdaOvPYlO/vx++yUex63zj0nW+cdp8gyn29rV9S1ub+3 c1b2dC0Glv3Z2Ob90dY5ulYrZabWKpu/sdogAQ/ea8Mo+nuoMQkQPWOVOJ2XKt7/Ad/vabt9v4dd M2Fbl412mOgvR4oLf4ToMUeqQosZJus5ZaAs6lvLYfp5hQW9WGFIf5RDMIUkXlBfVugFhwMzkWf2 IsqGXuzE8h8rx+UF+n430WiOEX9+tRwAv1vcxGUbtnCUjhoThr+wl8BGJJBNuEfpLpQXEsoRJYlC bo0VotRkaBFMJJprJ25jB+s52l3P08Vjt7NVop7hTP+3kKy1TdJal4C1M5snW1Z7Rf5qo9p202u9 dgK8jcM+YTUgo9SMPBv12c72uiznU37Z2rIar7J+J35hFz53l3XpNcngxGOhTxXQ79Z3nO10wM+2 bf+RVl+UmJTMUBJEnFbhwjvnVAklRc78VBdtxlvda2BU/SWjUQLxDd6dQ6cmushaOh5xNI6a71MU SCDBcdIJa5ek+oOc84Yoysw4IvJQRA9YItDxrSJufCPnOuooZbN9eU57GyUA3kvAZbDCcj4vi/xt O410VnSKbJLOeQ/nuy8VxpPoMkSfmSPOPCB9mKzvcIIbqP0OAvYz12bYMgF4q04nriiQvu9C7Egg sJgP0CL0RjlevyMn07d7/+LitL8tn48ftfsEpYaQq+wq/aznZIgi0IxWdK1CkuvpeXDRZ/Q7EWj4 u9aV8C212LaOddytgbXbRSFjK1A77FbfmnbNCCWrqQExJWlHkcgy3726j/33hFvsBVFmlsoa33rL 2bbvWR9Yahigr12RZU9fcJn9Z78H7f5jb7NJQ7ezxTPlhKySUTdHPHdlDM1Os/y1acoqqaDF4d2a Wjfu/oa8BCoogfgE7+EkOPVFVeikyCBbCUhRO+vvRvquXAWaAs6IDuzXwCxZrk76g6pMAgIQhL0j xvQ4Oasm4JyK7uAA7CxEYefRwHGPT1FfflveyI4ZsbM9Nr2TLRBX/WDx4C8QLWaNFpBfCMQQYtQU 2pTQpB9oMTBR7c/WcZ/qtxly8KPtoQI3hP2cofrMrI6KzKEoG7GeYbLKBso3XBMSWBEkZ5K+TtdC FF1tIl77ZaKOEa99onT5OoU7PVM5PFYoHC96PVbP0TgtTBVc0D0rjh8fBuo8H2P0+5hV9W11kBhN 8y++HtXMDqkacSqWcaJ4Li22zLKOPRtahx4NKlQ7925kTTvWUbhFSbGaX0v5OWnWuM0ixUN/xE69 9zE5ps50FJigLBPnnXCQWNTpWoHGHaBfRIIt7V4C4OdNbq9INHl2yKVvWD85vXbuNdnRa46/9Rll OV3tLPe1Y8ArT43Qf+Kcr12RZ9mu5sdZzXP3XigZxFOJ3lCRVTUK4SQ5hym8HomTthHHmMQ3FKId jBNYOl1xhf9QApF1NIQAiIVfJCTV2UcOiG1lEf1Y4f7mrdYEpW09V4K03ZHnwNXk386pMGRZdQXg T+XfAeALsmXy72AXoHRbwctr3Xm0FU6IoagM0TG51fJQkRK50ogosVaRS4y0Bt5ueaO9hMe4PlbE MI+XCBok0coJQn6G+b91lbiLaG/wgoPfyHGABZICSHJTVkxaI32oyNoWKjKI8/4/RV76UHSYr7Uj RX6LDO0MRWJJfEUA5G6y0u/MXjxL8LRXK8GPUvL89QbQs5CkxXEWu0vS8zXS+RYC9wdpDj638zT3 946DByjOe2yHikxPTLVPe92mPCbbWE5BeZPh/f1FmVEnRaEip8lJdEi1h4rMF7Bu1GKpHSegvfXu Yx23HcMWdJdfP+1jL19/jnXqMcUuHnS75a7JsAdPvNlmT+jk+O9EysoT+G+3zQz7lzjynXf8PfSK FMUGnvvwD3azt+88RedlKotmNTqtri9UZG70+BaxQEvLSLZ5k5bbj2+EQglXd3jQqoJq5W2XXaYi 1V2P20L601h5BqIniVbpe8iqW3mhIuMLvIcB9OmdptsDyrAK9eB7bc2+qJjcvFmObDvXOivB0gnK CjhaL50GAuds5SbpR4AZ9ITVshb0kJX+bTkhdhZt4bLftrfXZ3a0RZqgSLyUpBdQy1SFMBMo45zF iu2dLctCpsB9M1mecjUZLVY7hNXK1PX5brFeRiRWyhRQa6rjAGrL9O+GunZdtQeVgu3jJTouV222 DGflXCDrLAsOnLxIrMTnQn2Xr2QYNQ/gaz94X7dQAzhjed8UE2CwyIt8ul074Rq5EAzAeeCwx/hC J3AzdQjQxGbx4L1WgXfNPZcpYdjFXaa6eOzvizJ25she61fNjen6+nQ68nnRnNdPIVJfE/WGp2Cy wqoeLX+SRUpYZ/CkY7EU5Vt6crp9sdttSty39WbdwejPZ9izlwyudvBOp7GmE6u943ZTnQWdOTJn VR2bqmgyq5fVc3HeAfAFckYlwkzOapIv/TVmOaszZL1fbB22myaeO8mcZFSTdX7qyK0sW8fCfa/W EuXg3b0msAcmK7llpjJvOuHE6vugYiMb5EPIy1EyzoJNfA9X7JIVPsuD94qKTpM+2fg+6PuTbV9v pd2jLIC3jeseSmWvSSZVFhwS4ywT2N5RWVwfFT+zqRxrHA9ZZeKqLLtm0tZ2g5LlHC1nQQqge6Ss 9AcO3d3q6IV0/TYTbH9ZhFL1N2f9pt+uGre9tdRC4GUlK1mgrd5Df9hd56XYw8o8uHeTRfakqA+3 yzHrNO0E3KYQae+JLoHV6m611TCF64fiif+gDLF3K5LJvVtPcNk5z1YWz08VM3lHZW99XS8yrvcv OUaOE6e65pOVxAF4r6ge+vPCEvDgvVaBd82hzJ8NnQW9xEVLWhwk1KtMndd10gXwm0OrUcnDSKLr BPHkK/NS1daWMqxief+s7+3Wr/HWVlBYsUVIihIz/frZdHv+0m9rBLxjwCBKTL6iy7i8EypEmEkT kMdiXpif7Kzu6EdGVo6sxKLQBLuN7uASUWPEdVeW1sBBmd2YNHHlk1JlUa1uXBoD4D0kZP2vusML VdvDUb4LlbCKqW79KF/X1h1VmeA9vjjvmiR2lmNgV1nXCdn3lazrTRXx41k5UL2h1POP9Rhl1yot fVPF0U7SsSnarvtAjoaPCiBDTzigxUI7TnSb9/TdjGxt0aq8qZB+jypiSK5eHqfJon9Rp2mOh/nQ H10Vx7ieHdpygV2teMVzNSGt0KIAR8Xdmy12WQaPbTXXxewm8kKyLLdk5iQk4GJFXkjVVjK6+Kqy az41o4Mz6p7cdrYd2Hyh2sqwNloMnNBmjjJ2rbYBzRZa17qKC6xIDovg4cesJXYTnwR/uJeAl0D0 SAA/EM2Ts8RvnykKC5mCq6ToOrmi3XAdKtGXYhq4h4UE7shdUmB5C4oVHnGtavYm19XwnVcRmaVK JF92o7qJZFnHMxusVTbS1a5m1l+r0JWFcjoV/UlW9joN17jfE4jbHwncaZ33rgxmdSLPb7DanR/t wKxs4VThEeBW/BziuMabfsQXeNezA53FuZhCKddEkSZLEfSZLllr7N8dZ9hlW0xx0T1maSt2jrZh +zVZbEcLsJMkhwJV5juBfpwIKTgVviOg3rbuajuy9Vz3XUsde4yS7Wwj6z5lCwHr2Qob+O6fbdy/ D9Zx/AaXmT50zFxrF2w12fYWMAeAPy9nRpwTWTDsp++OUPpv+ujaVmKfl+a0sZVaLOyj9OJdtRjY SwmCKM8oJvJCeJ/eebEKZ0nftJeAl8AGJQDlBadtalXGZcdAEVynNsx3uD/ppbRgqt4Vo1fa7PEr bU4F6szRy23xrGyXpKnGALwD4VTofdRS2uJ+K+MZ+tv5NbUS8c/5+iTgDNxxXKNFK+ILvGvCH6No H8TPhsuOxfuPZQ3tqG/723GKtT1H38M3JxX3SR2m2yGiv2To7zdmdhBIb+3GrJCtYQHpjOCFQWxt /Z0mKz1buZRvFze1N3XOnZO3sovGbWcPTOui+MWmEH9ZzirfX9EWThe4XyZwPlrRE0h3f1aHmc55 drys9Tlq4zxZ8AcIlOO4NWh6Z/t6YXPXNg6O4xQT/A1Z5InecIms/b2U3GeSHG1/VTQGH+s7Wh4t 3w8vAS8BL4FySiCMtBdMWGPTf1phM4evqlCdPnSlLZ66VnQUXbcKMC+W8n9Yy8t5ixU9LLhmdV+3 ov2tree56EXSqYws+fDVS43LWkf3nZKmh6usxWc1KEHSLSplXWfomOk2cuIc69S6ke3Xt5sLaUUo qg2VNHH3FuavtJfmDxZYlcU6seaSRvytj1K8RbKYN07Pcym4yV7ZreEKW6sJqbs+4bETs/uVOe1s J/1718bLXOi+j8Q/30eUGSzokwWSv1Ss7UPkMNVOFvoZSpxTX5bzEXJ87aCMgH1Fh5kmSs0b4rGn CtQfrjaR1NClTW2WrOK76Pce4qtDe/lC2TJfEwgfIAs6MbuZawkhOFrXPLXdLNtSuwFfayEwTG0f 2ma+s/4D7t/FwVaLhSPU9o5qC+cwePPvzm4fjlxT1ohWx+9sK+Rbpzqt7LhWezqdKSr5K5RTWmKK LcpfZS/NG6wFk5Yr0aIj1SEaf42wBEI60rFOS6cjSfJOi9SReBATz0VSQpL938Kf9WxP1/Mr2psv 8SeBZO0Iiwq03Q/bWsakOrZ00VpbM79ANX8Ta6GtXChaaO4qvU+wvlcAwet9SEhHwjcS7aVY/YK3 DnLLUbSXAvHZCfeYmFS5CAZwTiCH4Hp0nUytucplAQ++SP0h8gxRbKDgVPb116t0cPjzFemoSYb1 OlTvdEV2KS6s3PuOFWUnik2xrJCzxy+1hdNW2bJ5a2zpnPiqC6evcmE56zRMq1Ao1rRU+UhOmG0/ jZ1lbZs3sAN339bS0+TfUYESX9FmEJAmogzxy89SiDH46R3rZDtrugvV50JFKnLBL32siSzzb4oL 31nAXAxCLUKSnRX+fQH5c0btaMeKb37PtuOd1XyYwPYeQ/o5Ss0jPUbbHuLVJ8rKj1MOsbxvmNTN XlJEGhJN3LbdWLtSjqn8fobaeXNmJ/uq/2BFGFjqqDiH/dzXRitKw/4dp9szPcZYM8UOJ3oMfctQ NJpnBNwvkaNqffXlud4j7IiW85UMKNVOHNXTvlDCExcbOSqKd1iNimGI6k54h9Va5bAa1boW7Z0r tNSSZHss9zLbpWgrW52wxoHvTS1pGak27bf59t07YxX5DNC9aW0AjHEqhbcOUJadXSAl0XIV8aWO uOe7H/u1pdfJtZEf97U/p7WWFbIK3jd0WWbeAvlMEHqyx76/WMOWS23V0voKhzjQ8tama/FAOMBN u7dNlaU7PlYcVit0c5twktYrqZnJWhhm26Onfm0Lpq209Lo4FW9CG7Xg0LXyKdn7rG3sqBt7yvFa fhybmEyhMh1W4w+8o0Ck6dZT2VaW9OYCx2lhxxmiIyzRhAHvnGkBazi/k6yOhDx1NWEsl9PptLV1 Xdzhbeqttvr6bqnO+V0ceawGDWVRB/BDo8GJirZm67eA/9lU7XVUu2g956xUKMnOcprlOitkZZgq 63y+Fgoparej2oIaQzSFbLVNhsGFckidKyctYsY/LAfbC0Wb+Vhg/6hfdlaccG3nVCXPdJMePg/e N0lccXmwB+8evMel4v/zpsPRZj7f41bbs+G2mvPl0FkBcJqakGajvp5mz53/g6K7YKkuP8DFsl0k 4L79PsOt75HfWfOO853z6Jrl9ezLZw924Rqveed6hYJcYc9edIniye8qCkW2A/d/FRmtZKXHcOXo Li6sLaFQlIQqnAXa8aXJYRJ2VsWKz+KgZed5dsZ/H3FW/ZeuOddm/raFYr4Psr1O/dQ1//uwbWyG wkv2OuRHgcfW9tqNZ9rKRQ0tJT3f7RCErkPUFfoQ2uUN9SEykaKkqt84plzFg/eQmCLB+2nfyPIe p+B9ucD72VvbkTfUPHiPL8578LQyichyPUcUmJGipQwVn/wnZbD8TZkrSfTBY40lfrqy/f1M1kvR ZCYr/CLHTlstXrke/CJNWGN1/A86d6J+c4G9APcC1yOXhNocpnMdcA+SKem8xQLzw9UOba5UVBna mqbrcP2JsuDnhwF4gcD5FHHY+f7XxU1sUvj6c9ReiX7rK6rNv9rMU0KTZHtWVv08LS6iB7iXa1r0 B3kJeAl4CXgJhCVAcOHCbL1Jckssb01RhapMRqKYbHqsa0eP0Xtl12MG20l3PWnb9hulcI2p9seI booWs8b2P+f/rGWnebZycUMHlIv0nhJEdlQWAHrgwEgbDkirFBXo73DyQAB0oQxfzg9Vf7vzQpjQ xXxniUH2VAD67z9vY2sUE75uo1XWUTHhKR8+eIz994Sbbfz3O9gUQPyYLda1wflQbVx7+r9CXbdA 1wqcZR0dh35xDGDea9xmSYAFYdxWxdPf1N2szRL2Rk6OT/COQJgt2HqLTF/PvwNH1CCaQfB7cKyo K65E/u628MKFFX9km6UjIUT+HljJg7b5DCwCf7t+OHoD7dKeziPd+Bkjd7J9h+7qwln6CDNV9Yj4 dr0EvAS8BGq3BADWjVousb3P+Mgy6ubYV88dLLB8iz1/2cX26BnX2svXnmcrFjWylIx8J4jCvGQX e/2Qy96wi5Qx9co3b7RLX77VTrnncWu/7XRbLYrLzof9YOc8dr9d/X/X2TlP3mcdt//D1iytZ622 mGsn3fmUXfHGTXaFztvzhC9dmywCMhusceEksehjdactys6HfW9HXPWaJcqqn5qpJIiythcpEy9g fMf9frGz/vdfu/KtG+2yV/9jx970grPir1meZVv2nWDnPXWPnXTHU3be0/fYJS/d6voB9cYXL4FY lkD8gveYHrVimy9+/Kfz2tjPsuD/LStnLN+X77uXgJeAl4CXQLVKIEQrMeu261hr0nahs5hP+3VL W76gsYByri2c0comD9tW8eOVDTVsvMKZlcRL3XYd50JSTvt1K0d36XnQUNv16MHWdeeJdtCFb1vH HabY5J+2tQbNl9nAMz62Rq2W2u7HfeXA+KKZLW3ZnOb6/iOB9GmOytLzgJ+t96E/OH79kjnNnDWe Aj1m6dym1rj1Yttp/59tuwEjZckX5XTH3+24W561zjv9LppNFznUZthu4uWzqADg19GuwVZ9x7nr NRJvHrpNQU5a2AG3WsXsL+YlUKkS8OC9UsVZjY1hmRcf3ln5y8vfq8bu+Ut5CXgJeAl4CcSABPQq ATjXa7bcgdpC+V7BC09VVLZEPgXS0+qQDRUeeYhDD1DHsj3ll62VTTVNlvK1jh9PabP1TLcQwErP cQUKqPD1cwfal08fYumyqDfWAoHCtSb/vK29ffsptnh2c3H0Cx33HepN9so69tWzh9iy+Y3dsV88 fai9e8+JzpmWkr2qjmU1XmW9D/nBMuqJdy+rfR0lg0rXYoPSYbuplqYdhDxFxqGwAHn2kotVL7HZ Ezu6XQNfvARiWQIevMfy6Pm+ewl4CXgJeAl4CWyGBADR0E/m/97OAXciyEBPyVmdKfCb5kI15gOq CRkpkF8Mx11/d9x+qu0wcKR13WW8Io/k2OwJndz3KTIojf+uh7141fk26YftbeDpH9vBF79t2+89 QuEFmwisn2aDBx2g86fY4Ve9YruJZ09G1QCYQ0rnOiwagnCQWNHTFOUm8OEtEq+ezK1N2y1yd75i YWPLF/f9z6lt7IfXB9r3r+3tOPvJqSFK68pFDWTlb6pIOdmWTLbX0pldN0N+/lQvgZqQgAfvNSF1 f00vAS8BLwEvAS+BKJCAi8yCFXxYd5s9rrOzsA88/RMXFrJZ+wU2QNFejrvlOVFqFjlADE0mQcd0 6TnJGonGsmRuM/vkf0fZzDFdnMUeAL9Vn/HWquscG/puf/vqmUNcqMc+R3xnbbrNsm32GGNzJ7W3 9+47Qdz4Brb17r9Z222mWx5tE6km7AsWihoTci8NItgE4D1VVv7lssr/MXxr9/tqcenfvftE+/Sx I+XsWt/FqHex4BUVjpIkwJ6SEVqUVLS4+47nKrT4V9qAisuxovKPpvPYf6qILjj9JQCT+y9Snpt+ d+UC7yVKxlAoL/Ziwj3J2zYpVTVlwzVBvyfI2bsQflwSTpZ8+hp/MiiwYm2brk9XEqQ/Xkf8M8H8 sE5HyphXNjbnxOxv3DPz5SbG4970qd6f4SWwfglghQYM54ov/uZtp7qQkHDVz3joYbv8tZvtqOte tLZbT1eCniTnTEoFeRAqcvGsFta8w592wXN3y8H0JXcBLPNJsr73P+kzF/pxl8O/c1Fgfv20j60V 1QYO+sn3PGGHXf66NWi2zOZNaWdzJnVwVJY0UXWwljvQLpCTFA4GkUSgBi0KEsMBILDEY6n/9dNd tBDo4Nq8/sOr7ep3r7P9z3/XmqlPhL1MVPIrSori1ocgUwWL+kJmzdRk7UzUSYrLmqq0vcmpRPUp UvQexTUq1me81SLppvCwJLHJOpAqvZFGG3g6D0RNojPN/RUt6+K8k0WMGtlUkJ3toTe/tWf+7yfb a6fOds9FhyoGucI6KcvU+gqPR2Zyho1bM8cO/fVWW5a3XA+c9+yu6ADF7nkJ2oJdbXs1USKqHa+x ZC1T84tcQE03haIjE9bOtUNG/kdJppbLEcrrSOyOdUV7HtKRfk12kI5cZ8rbqFCpEZGbKtpsDJ2X nCiagbINnzL+v/bmn18LISgUbcUhRgzdue/q3ySgOO9knf6k5y02oPF2tkrPRUXivNfJShOonm4v XTFUQGvT4rwDsKHINGmzyLaU5TxTXHIoJjlr0m2CaDBEkNlx/2HOUXWC6DDL5jW1LXpNchb2ZFFt sH5DuYFuA5e9ddfZ1m6bGQ5Ar1jY0MZ9u6MLAcn3W8ihNVP8dyz5v8sZdvaEjnJmXWLd+49yQH+8 juW3bfuNtroNV9tEXQ9KTKstZ9vWAuorFjew3+UISwz61rp+p50mO+oN1valouZM/qm7rda12op/ v6WutezPxi4EJVF1gnjz5dXAwoJCq9eoru1+0PbyA0ixwg1gn/K2F6vHJclwm59daBO+n285K/O1 QCuX7TdWb3e9/S7IK9LuUUMtbpu6Bcwm5mjS4i/JJkz/0377409r0bie7b5jF0tX1tXi8jTk6GSi q20nx+3uSXJ1VFk5R1lCX5llK5SOGefHdQA+/MeyFWttxeocy5TiNm2ouOW8XjZysURdIE+T0by8 pVZQwoKg4quLWjXycXYzxRr7ugLlrdMb/UNn0JH8kgKbm+t1JM7U4u+YJVJHSN4SZ8A1SfkikotT 7KEdX7Yf2w03y68Tz+oQv/ceBeDdCV+v6kJxx/Pl6OmSL7m9/RLnCJokiziOogBkOO5JKUquJGBf VBBK7x6izBADvNhZ0YkUU6jfsOwnKq+KO0fWRkA5Tq5BUqUUWdtZEMBjz1ldx6GF9LrZzlk2e02m lRDZRufiEIvza552CLh2upxouWZ+bpprU9QA13+s82kZ9JeY9zo+nJGVEJgVgSLFAmnpGRnWqWNn S5blvbh4/YbLWq+8gEfFeCezaqKMDg65xhm0w6Cdn1toeVrE/EUhKv/II7KMtBRXC6VXOfkF5V4A cL2CNSXWpnU72+7fyo0AeB/7zjL7edBcK0oIbS2VLilKs5ysysXy8su2jNFCkq6UmaSQTG50K7xZ VX6p+COjUAKyrAqc5RTl/aNvgY5kSEfkBuV1JApHr3q6tGEdqZ7r1+xVEkUFSFZG5ecOeMuGb/Or WY6yJ/sSfxKIFvAef5Lf+B3r1ZS3tkA0nAZ2/O17KqJNmhY3oR1kX7wEqlMCKZmJNuPHlbbil0zr HoD3395absNfmWtJjQqsxfZa+Yp/WVIcCbjjbHlVnSPir+Ul4CUQtxLA8p4i/uQdLV6wwfV+VlpK b3mPS2Xw4D06h13QJ2dVvug3je3yNw7WDkRol8EXL4GakMCUIcvs9zcKbfuzZBgPWd6X20/PzbEG XROsz9ltnFNqcaG3ltfE4Phregl4CcSPBMRKtrSEVDvnzwft/1YM1pZlPd28n3vjRwPCd+rBe9QO eV52yPJ+gizvGfVkec+Pb8v7xijTUTuIldixEF1m8wzaf5dh+eb7lMwkmzl0pa0cnmnbnaHITAF4 //Hp2daiR4odeEtX51FcXFS+BitRJr4pLwEvAS+BuJIAvh9yPbITR91nr87+XInXvMNqXClAcLMe vEftsDvOe3q6OO9dFFghjjnvMirAykjPUmgBcd/j0cYAcM/Pkd9GDhTzTQfw+HQFnPcisVvyZSQv L9JG9oVrS6xV09a29ekiG0eC95Y9U+2QW7eSU8mmdypqnzzfMS8BLwEvgSiXwMkj77eXZ3zmwXuU j1OVdc+D9yoT7eY2XCBLe/3GdRRtZgc5wia7KCPxWHBSzctRtJkh8+S4nCecGH/RZth1adOtkXXq 0cyFySw38g4rTHJSKNrMmCnzrWWT+rZX726KNoNTd9kQ3vmO67+W7ZpYwx2K/gLvQ5+dbU22TbKB V8mjWpb3ooL4VNB4fCj9PXsJeAnUjASSZXlPVcKDkyfdZ28u+NKHiqyZYaj5q3rwXvNjsL4eyI6Z u7rAWm3V0C55dW+rK9pMfkl80mZSE5JtxZJse/CkL2zBlBWWkQXojM5hq6perV2eZ/ud393+dfXO iqRYaIqvVO5LYRJPTUi3x/5viN35wmDbbYcO9uwNJ1hWWka524g8cJ3lfdgLcyyzXbF1O7iJCwfk aTMVkqc/yUvAS8BLoNwSSBZpJlUuq1cWPW6fFv+g87JUy/9CKPeF/IHRLQEP3qNzfALwvmVDO++F vaxOwzSFn4xD8C5bbmqdZFu5MNseP2OwLZy20oWMjLepau2KfBt45tZ25HU7Wc7awnJZzCMVO6tu uj3x5o92/yvfW5/u7e3x646xenU3A7yPeWOZjXhtvpUoNmp6PWVggs4U8f4gtmUomJ/+24T3SigE oC/xLoGNrU69jsS7doTuf1MsGLVJYoSKTClOtv/t/Jr91H6ECJU+VGRtGt9y34sH7+UWVbUeGAne n49j8C7cl5oZBu//9uD9CIH33DUVBO9v/QXeH7v2GKuftRngffIXK23o03OVUEGdWQ+fK0mWeOhN hSLXZ+flu2dnY7AckJ+k7eCspAyXEWqTEH+1Ppn+YlUqAS362FpaU5j7D50JdKSudASnPa8jVToS 0ds4OqKsqmuK/qkj0dvpyusZ4D1Jcd5fOOhtG7Gdj/NeeZKNsZY8eI/OAfPgPTQuHrw7MQSW96gB 7/lrim3Ob6usQFmjFLlsXcGzFpv7p0Mn2Hcjp9pWHZrZsfv2cAmYCjeSZSw9MdXm5C2z/85431YW rrUkpX2Ou/2V6JyKqrFXAmUCZNtltbcL2h/sEjEVRnAF06Qj86QjD8yUjhSgI9rx8SXOJICO5Nm2 ddvahR0OFoFEieDijE+arHtO0X+XFz1pn5R8r/H3tJk4ewhCt+vBe3QOuwfvHrxHaGbUgfeynpp7 XvvSHnx1iO3fZ0t7+oZjlFIEi+r6eV9YVNMS6ti47Bm280+XW07eUsUuZltgE/g2ZXXI/x4DEiCX 7yrbvfkuNrj3XU5n8mWFDy3iQzoyIWem05G1uUukI+kxcE++i5UrAXRkte3arKd9u/M9grBJ0hFC cMVPwWEV+H7CiPvttZlfaW/ax3mPn9GPuFMP3qNz2D149+A9SsF7uWL9JOQnWIYSiSQX6eW6tkjh glTXbLiW6PeiNWaZeQLtecoYmCcep69xKIM6lpqTFtIV9CZCZ0oUcgodycj1OhLvz0ZqbrrTDTe3 bGReqa2/FWUXh5LieReh6ARwvldeAl4CXgJRJoFygfco67PvjpeAl4CXgJeAl4CXgJeAl4CXQFxK wIP3uBx2f9NeAl4CXgJeAl4CXgJeAl4CsSgBD95jcdR8n70EvAS8BLwEvAS8BLwEvATiUgIevMfl sPub9hLwEvAS8BLwEvAS8BLwEohFCXjwHouj5vvsJeAl4CXgJeAl4CXgJeAlEJcS8OA9Lofd37SX gJeAl4CXgJeAl4CXgJdALErAg/dYHDXfZy8BLwEvgQIlvytUcjNlabX8VCVQiIg1yd9B3ZikNnZc 5G+RbQftlfV76euu71oKP2x5aaH7qKpSuu9cE3lRkR1lffdXkf6UHpOg/Yq05c/xEqjNEmCKKk6w nNWZylyaZUWFei5Vgn/zXVBz1mQY9a/v6upvauiYXP2Wu5bf//pujb6nLVdqYRheD95r88Ph781L wEug9kkAoClQuEeLBdazyRJrlZlth7abZQ1T880ApgDh0rU0sOf3AGgGx/LvAGyW1U5Zv0dKnTbX 1ye1sXWDFXZCp2m2k+7DvV8rC0QH1w/6ySdFfelaf6X9q8NMO0nXbZu5NgTig0VQRbUlvDDZvflC 21W1Y901dkT7WdYiPecvmVa0bX+el0AtlEBRQZKlpOdbj32H265Hf2P1m66whIQS237gCNvtmG9s 9+O+sj1P/MLVHfYeYT32GW79Tvrc9jj+S+v7r29d5e9+J39u2+890rbedaz1OWqI7Xbs1+6cvU79 1HY64GfXZklh7YO6CSUqZenFvYO+sifeGWoDe3Wxh644XKnslWG1cMMZVrOS69hvq2fbwBE32NK8 5eHsmWVepqxu+N9jSgKh7JkDmva0D3a60ZITlGG1+K8Mq1nJmTZuzVwbMPwGW5K3TDoi65svcSaB kI70b7qjfbjTTZaakGR5yjQZT4UMq6mJqXbibw/YG/O+NkspR4ZVAdFdBHbf23mYfbekiZ6rRMlw se02pL+tFAg9uf1M6yVQnJ5UZCsEyH9e1shem9vWciOs23s3X6Bnc4m1yci2TB23Rr/NVcK0N+e1 tt90/JkCtn0bLVPfil07q9TOt7rWyzM7uuE5p8tU691guX4vcb+vLEi2rxc3s9dmtwsl004qDg2j +pqaVGjHtZtjfRsus8ZaYBQK6A5d3siemtLVru42yW7tNtFen9vGTh3ZSxl2pRO65maX8ALnnM7T 7JAWf9oHC1raU39sYVupDy/uOMp6N1xuXOVBfceiAbD95IxO9uWfLc2SQ/PUJhUWKAIJQ/f4zgr0 9/sLWtiD2463w37uax/o3oyF1caKz7C6SeKutoN9htWQqPVMp2Ym28qF2fb4vwfbwmkrLb2uFvsV hHUAaqzlTTsssEtfvtUaNF9mT557pU0b1dWuee86a9xqsRUXJaomOfA9a3wnS9Cc0rbbTEvU/JAY nl+ctV7P+vTRW1hyaqF13OEP193CfOXr1nM8Z2JHe/jU65UkMsMtFDa3rF2RbwPP3NqOuG4n9b/Q ygGf/3bJrLrp9sRbP9r9r3xvfbq3t8euPcbqZylRZQVK7VuOVEAI/hQvAS8BL4GYkEDYMn1Zlz+s UCBxvrLTntR2jr0+p63NWlnfDm413x7uPs62zVpt7TNy7d+y/v5vu7F2WMs/nQU4Uy++K7v+bm/2 GmFXbzHFdm+81BroJbeXwP+1+veJasv00jxG7Zzabrbtqd+b6neu8bxA761bT7RG+vfRreeGf19i TVPy7RQdO6jHKLtFYLwuL9YweAasP7z9b+63s2Tt7lRnre2khcUj246z0zpPtRXhBUVxsK8NCGYH IKC1BFZxByBY7EX8Fkm14e/gHI4Jy4nFByA9nQWBjulRf4UD7pNWZ1mfb/vb41P10tfiI1kAISVY NLg+lGovsNw7ZBDetQj6wr91vb2aLrIttQgo0N/7SJ7L9Pt8KEFa4PjiJeAl8E8JlOhZCegy/E0B rFPevPV0u36Px+y2A++zQVeeby9ddZ7dsu+DNuiq8wXG0y0/J9WevuAyu2nAI/r9Alu+sJE7b+Qn fe3GvR6xm/d5yJ65+BK3AEhOq31GIQ/e/RPlJeAl4CUQKxLQCy5RL7f6KQU2WmB99MoGtlrgcfCi Zg5Ajl+VZaf82tN6fLmvrL59bFp2prOsHyTrM/h472aL7E4B8BQBymvHd7e+gwfYXl/tY32G7GUn jeht785uawnJRQ6AUv43o6PtqbZOHN5bVqYEO1+Au7sA/TJAKb9P6+x+P2VEL9C1XapFRXeB44CS c0zb2XaOQPvcnAw7Qcfs/l0/6/fj7nbmqB1t9LLGlpYQsrIXqW0WIzvK2n+bgP3TWlw822u43bv9 GDtYCwUAcyPd84VaeDzFb71/sUP1faKjuyTYwW3m2gM9RtuL2o24Rpb8uljP1eYM3f+4VfVt+IoG 1lcLkos7T3fXS9UC48jW8y1TC4+h2mn4TbKco4UQpa6uc2aXafbETiPteV3nru5jbefGSxygzxDA v0x9uFV9vHKryfZ0z+H2b+1SJKjv/bSTMU9tvKXdi63rrbYHtDAYvbyhdiFqH3CIlcfF9zP6JVAS puoF4B0ePGXV0nq2eE4zWzq/qWoTWzSrhc2d2MGWzG7hAD914YyWsq53sEUzW1hhrhbtKvDcl8xt bkvnNbMVCxq774IFQfRLo/w99OC9/LLyR3oJeAl4CdSsBAR2iwUgLxzdw64Yu719KjrIgO/3tGGA xPRcG720iQ3+s4XtLT785VtOthZpeTZ1bR17cnpnS4G+IjCNlflLgf0HpnYRsC+2fWRV75CWa9NW 1bNZa+uGOKJh61ducZKVyKI9bU2Wo7tgEwNuB7Zk97uA/AydV1gSvE70q17ITWVlh7JCGb6ioSg1 7W2trNHz1J9np3Wx4Qubi3ITAu/8PxYyjr9AlJx2ovN0lhX7si3+sEdkud9BOwmnqJ+PaBdh+3or tbOwxp7eaZTtJgt3d13nGVn2j2szx5qlFth1W/1uNwhYA/gPkhyu0Y4Cn40li1aSEaWxAHqfRkut tfwFztCuwQ1b/m471lvlzrldi5sndhhju+j35mn5dpH680rPkbazFhbsSpyk3Ywb1f5d24yzvk2W ajch2xK14Hlueic7algfe2VOOzvsp772kOTrCDi10FmuZh8Cf/XaLAHmAcoxNw6yO767wG746Erb U9z2YoH19Do5lpqR554pMXEtrU6uZWRlW1pm6DsKPPdbv7nQbv78Ujvtgf9ZggwV0GhqW/HgvbaN qL8fLwEvgdorgfALasrqejZF1I+leak2QpbjFYV6OQG4BaDPFWh/q+9Qu0x87zqyui/MF7heU1d/ F1obgVXKnOwMyxSl5WoB0Df6/GSfiKv9Tf/Bdp6sysUC2MVha9hhAr336/e3+/7kqCdvib89cVnD daD7cNFx7tdvb+zys2XoWi+LvjNOuwHw1psLKLfLlMOmSrZeyHBQHZ9dxzkOuD6DRUCAb4eJC/+9 FiAjBfYn6/7YVWivdo7uMMP2Ek+fMk5W9P8KGF+lnQOs5X3lINpc7S3UIuJNcfsv+G07+2ZxU9d+ bhgIQBf6ZGYHe1S8dsr3SxvbPt/uZd8vbOHkQlmrY3vIl+AELQK0JNGCpI6NXVHffd9FC4Q+jZe5 9tYWhSLjPCawvofauGn8tm5BNUtW/j/U5xwdM2Z5A8tmV6Ay+Pu1V5v9nXkJ/EMCCeHduJljtrBR n+1iY7/uaQunt7KklLCfZSQLDYOCcxb/q5ml85ra6C92sTFf9rY/RnRzv8GTr23Fg/faNqL+frwE vARqvwQAwgEYlhU5BNyBwCX26O9b2RFDd7XLxnW34bLI7yonzYdkSa6bUiiAWcfJpp1AfLYs6nfI en+Ujh0isAslxFnCsbyHJbh11irbV3STRblp9h+1e/247W2VzktJDL1Iu8kKvm/L+TZftJibJ3dz QHYNVi4B5+UC03+G6TWparMIHjlgOgjVKHAbgHZoMxm6n55ygu0nisoZAuvbyvK+mkWJylJd86ZJ WztKyr9kKX9YdJpdGi61JHX0/2TRv/OPrm7x8MxOIwS+5zpHWxc5J3wjwY5BcZgOxPVyoeo4iYUK r/fusrZDzwGAd6ibbQOaL9JipL59ql2CKQLzKZJPcviMr5Y0s2W670Jdy4V9YFHCmDAWkrUH7rX/ MfR3WPkSwFJO+eaFA+ypiy53fPZRn+9iyXoug99KX5UzsMRTpv26pb1x8xnizJ9m3760vwP37IzV tuLBe20bUX8/XgJeAvEnAQFVrOz/UqSZPWWJ/nZJU3tEYPoX6DQqvQXgAd3/R+QTlb1FN4Gfvkb8 0sHzW4urHY54EEay8OopT8ha3Uec+H6i5twycWtbJmCeKoAavDiwPvN7f/1+66RutgywzYtSfZkn a/9nsmxToKicKO57VmqetZUV+99Eq5HVPjds4c8T/aaDQjieKFpPPbV/1+9b2sni2c/QDgFgGMfX NqL2PCHL+SmjdnJRdODS76c2mmXk2ChZuk/V92/Oa2P7iNd/rXYQ6GNRJGdF7SSF78vdH1Erwv+m jxw/UbsYawTc89SvGyZsY3t9PdBu1n1BM5qxNtOSIyx4LBYcYI9oI/4Uz9+xl0DFJQBFL4gCQwQZ AHiyqG+Ufqd8Zqff94ideMdTdsglb7mINAW5qS7STKoix6SI0ubAfHjOCs6DRlO34WpXM7QAr63F g/faOrL+vrwEvATiSgJYt4+Ulfx1OXRO3OdLG73P53Zhp+kudOH/zW8l6kqifakQhncKGANa71Eo wzF7f2W/7PeZ+OSznaygt1BYCFAAu4SRdN8DUnnB6r+sdeEUE/R7imWHQyX+zdqsY14S+H9ZHPC2 Atgvizc+Yq/BLpwiHPUd5NgaWN4bynF0jizcQ7TooFyuhcUne35ne8g5lmO43lkdZ9jHovAQFQfu OgD+d9GH+ojq8k7v4fb0DqNtZy1SKGNE3cHiFvTTAW2V9PCOQUCVgcVfN2yV455H6vofyo+ggax8 T6uPn+/1jb2/yzC7WRz39rqHIt1nVnIIXDjrfmXHpY8rjfU3G88SSNC2GTz2BX+0tsVyRiWCDOEh 501uL6fUZta5xxQbcNqnLt57r4OGWp1Gq61YtMDc7HSbO7mdzZ/SzgrzUpxVHRAPXWaZHFupUG8C S3xtlXHSLSpl3dzQMdNt5MQ51ql1I9uvbzdN/AniRG44/FWa4hYvzF9pL80frO1HOQglVmH2vLI6 73+vIQmQSCZfzlyt7LhWezqdKSr5i3eWlphii/JX2UvzBgsYiBfrdaSGxqkmLxvSkY51WjodSVLM 80gdqcmeVde1eS6SFN/+/xb+bONXKxJKRfMdEDdZXGyizyyAqqJ/Ly1Icxb4JwWgsVjjXEpM+MH6 boyA8oL8dEdHWVOcbL/I4vyhYpz/35+tbNH/t3cecFZVxx8f2EYvgqJYUFREBWwgNhQQe8USjd00 SzTGron5R40xtsSosSVqEmPDGI1YsIBEBEUpCnYRARVRQFDaLtv4z/fcnfXy3L7vsa/M4XM/y3v3 lDm/c969vzNnzszqNtJeyfLiskJ5TjXnszC1gahWaZjRlhUp0SXfGPXtjkeb4Nc98WCm5lup9Y9R rfUCzbtA7dO/0To/1fx3qb/4v6lM7fXFC61+XvNMVXv32cXtZJn2Y0WFEnM9JPuC1j9TvcXgf/6Z hRuGhQNppsp/nZrKjFFN+ydqurJUFxD5emuB7iA8oHbv13+0TdCed1DtHHbz7ADgHrJAzVkqlACM VTMh7OrpU3vMiYrby/Pa1nxtf5LuVixUuVmw4Hd+mua77uM+8ryS+nzFBe89s3RX4bmFPRRr9VCT DFeQ+mzM13lwYs+h0rtdD5VdtYpNOOlaWJSvpGapzHjhM9VQtlZS46dlm/VbVvjKSyulY/e2MuiI LfSwZL4Sztx0/ZlX0FoJdplMGT1HVi5drRryqsBnTQJYn3v62y/VZ9WMcQNl8uNDZekX3cKh9bdf Giiv6eeJj46QVx4eIRMe2V8m/3dvWbaoazisunJpR5mmtvBTnhoS/o9/97z8SpnzZp9Qbva0vmrj vqZWE5smiVtVqKykQnrvsr5sO6RnmBeNTUWF+TL13U/l1ZnzZNMeXeSQIf2kTVHTDtN6kKbGou/5 G4gAPpk9SFMDwcrRbNEc8SBNjQzSVNdsQQOuJH2t4ClVJiLVWnG0xWjSa9Iao6Gu8okebMbNrj6x TcxjKM9hz/oOg5Ev7pM91KUECI03bSCLmaDY58T2qjTnIa8l2rW24/2Br6Jhp0xwJall7LPVDya2 e1Dlpz3kN1t51QCutRoJB22r/Owk5k/Gr9eDNCUDxeTXoXOpZHmZ9Nymq5x933Bp37VITTeyz366 XuD055LMIE3WXvDzrpFW+Zuvi+jgGUbPxpi7SMuHwoADq8ETVigTKYTzKFOlVMB1JJr7PP2dpsrG 3YM01TtTPIMj4Ag4Ao5AoxGAZGLWYQda4wdbq9+EVcQ1MQ8HX40Mcy/++XtkmjZi+esSNBzgTJCJ A53BDEeJEPeMnAf5qw7jxv8aUY9/Z/bmRsSr71XJFRYXHCKtpX6T2Q6aWt/5i3yJbdmKiAVLbYua Rg+YF3AEchcBiDea8wINomSHUSHxfI5f5DGSHpUpC1fcfzuafMqkirin2yi5zXu6jYjL4wg4Ao5A cxGA0NpVW13xPDUduqzrICba7cYe1KxNpsR6EuWK36+rX7X1t6b645jUVa6me03pe3PH08s7Ao6A IxBDIMXkPTzl/Mp5DOpUy+X4/FiLReQwFrn+XPbnZHq+K3ReVps4r4sxyvXfgfffEXAEGoJASmze O+W3l2nL58qer14oq1fr6f88wk7n5iGPhgxCdubBnnmZ7L7BbvLi4GulQA/mra6MgqHgRZo58uaK ebKHzpGSkq9zd44UqO1wYaHa/er2fkkU/TF3UjRHBm+wq4wd/Acp1AN7q9X2N5dSvh7SLdQD/kdP /708+dkYNdfo7M/KdJoAbfS3WaA286X67FqdqrkZHdwWPcQ/Zrfr5cDuO8sy/V005cBq+45FMuXp T+T+iyaFA4Wt8/zAarOmk9u8R/Al2eY9BFYKqip2CL8bIfvevkm8H8kSRXoO5Ru7+9esyaCB3L4p lRE/3U6O+tUuUrKiXO3vG8drO3ZoI3c+OlFuemCC7N6/l9x++XHSuWOVm95GypZ08k77bdVjwsfF X8ml798ry/VAWmt9OXnKPQTKK1bJzp23kav7nKqeFFpJ2ZrvDvq00Tkyp3ihzpF75NtSnSN5OThH OKu3YqVUfPONtG7bVvK74v1Cn2SNex5k9MQqL18lO3bpI7/b5lQp0LiWZWuiBV6uJDzs5LfOkz98 /KiMXzRVvZlEQZQ8tTwC/BRnfbFEvlyyQnp26yBb9lxPD9KlRq5KVWzk5+XLNX1Ok10699borESm bTzxhry/MXq2/P2Xryh5z3fy3tzh0md0ybJS2bjvenLuv0b4gdWvVskdP3lJvpr9rbTpwKH1RgCs RLuiNF9Wq9epNRVVc1v/FKpHqMJ2q4OryDJ1/RhP+HRv06E4REjlQGppcVH4a4n7Re1K1M4dt62N kKWJWbOevINLOPDfKopF1/hHUBOR9WJphUA09vqDjZH2uIA5PUeUGbRqWyCL77xbvrz7r9JhwADZ 9JY/S17HTrKmNFUavrSaHkGY+uZI+kmcGokg8Ws0TJA/K1ODb2NrbYWbRdVaX3HLU/Lwc9PllMMG yZU/Pzi4CVxTkXwGz+8gBJXSZ+V38W0bKbVW0q5TkUxTzfs/LpwkBYWtldT4jGokit/Ljoa1Z5+u ctbfh2vgH/c20yTyziZrcaG0aV8sgw6fKOtv9lVwFbnymw7y/qQB8om6eew/bLpsufOH+rtTt6lV XmSWL+kkEx7aX5Z/3SkcUCXP5jt8HAg/0ZK/nL2JTH1mj7AoqPGgqhHQEMtJ37nN1NTnDHnHf7Gn 3EaAF1FdvrvxbZyTScl7fvu2Mu+iS2TOH2+Urn36ynavvCJ5660nlTlmPlPfHMmF+QF5b4qZRC5g 0xJ9zFPyXpCXJxffMloefn66nHroILn2nEOltKxMLdxSp+KLyHvTE2R9lW7tL5m/MmjNnLo3HUsr SUybwjb50n2zDmExlKrdl+ZLmsIammk2gzvIovYlMvKSh2SPo8cH0v7toi7Sc+vPZebYgXLLj34t p994u+x13NjgJnLhvI2U3JfLok97yH3nnyfFK9tqlNVRMuzk50JE1m+/6qp/y6Rd5xXy1J9/IGPu PEo/rw7+3UPC3GlFG3UpSRCn8hAMao26icW1ZBuVo1V97m1rgTInyHsKp5FX7QhkPgKQ9w4d5NPL LpN5118vXfr3l75jx0qems7kGnnP/MH0HmQbApD3fCXvl932lIx64U05+ZCBcs3Zh6ScvDcXR0xw 8zWYTkHbBF//za04l8tjyagEfvXK3DLpW2vIm0HesWPH3GWnAybL6TfdHjToD/3mpzLunwfLXj8Y pztEZfLKqBFywtX3yD4nPh806Xf//MKgmcdFZKlq7Pc+4UU58Zq7dQzayjO3HSvTnxss7busUE38 tBCd9a0Xd1UTsSjSKuSfSKw7jJgi3TZaLIs18uqGvb8IAZ7ma2TWt17YNXjKaq0RXhub0om8p9jb TGOh8fyOgCPgCDgCjoAj0BQEsNOvKK8MgYVKVviVFAwUy5wm7k2ZiLEymKpgm/7Zu71l4dyNwp29 jntJDj333zLrje3kxXsPUxNr8kRn4tp0XCWb9J0nm2w7V7r0WCJdN/paBihJZ25jXvPS/QfJ1/M3 kC9mbSJPQ+SfHxyCM636toOs0IiryxZ30fnfVgarec6RFz8kp6lGf/+fPSn7/3S0nHL9nTLkh2PV tr5QKpXkZ3Jy8p7Jo+eyOwKOgCPgCDgCjoAjkMYI5GsgtsWfry8v3nOY2qlvLJv1my0jlVif98/f yW4jX5bVqpmHgJO232uGXPHUJfLr0ZcGst1tk0XSWUk8qXRVkRS1LdZgTKUhIFNbJfqkrXZ9Xw47 f5Qcdt6jcviFjwTbeezlSXOU8N9w7DUy7r5DgzZ/ix1nhSitNUaYTmMME0Vz8p5Bg+WiOgKOgCPg CDgCjoAjkEkIoHlHA/+/Bw6QW0+/Qh749Rky562tpMcWC9Qc5q+y7V4zpbSkKCLbM7aW+y44V23d fyHP/uUotY9vH8h9SFpHiZrO4HGmoixfipe10zMeHWSrnT+Q4aeMkeGnjpF9T31Geg2YLWWlkeea 917ZQT6a3E+WfLF++Fyu5bIhOXnPhlH0PjgCjoAj4Ag4Ao6AI5BmCKDlhjBvuv1c2fuHL+qZjDIl 5UerF5kDgra9U/dvZf1eX6kXp4iOLv6sh7z6n2F6DZUP1BPNgo83lY9e7xfuUceA4dOD5r19l+Wy y8GvSb+h08Oi4Nojr5PrjrpWrj3iepn8xD7SrqMe2tbEIVXcSfI3m5KT92waTe+LI+AIOAKOgCPg CDgC6YKAngvFf/tWA9+X0/94m1zw0JVyvl4HnPHfYAv/ltqsz3hhUDiASsKDDMS8fdcV4f8Q9dce Hyozx+0i3TZeJGfecaOcc891ctZdN8rP/vIn6T98mrqS7Bw060u/7CZL9OJgK/7hSYXqhYYFBAdl 7XOzXDqlCa5O3tNkIFwMR8ARcAQcAUfAEXAEsgkBPMBgn/7G6CHy9K3H6sHVLaRj1+WySDXsz905 Uh6+6kfhoOnn7/eSt8fvoodYtw0uH4kRA+kuUvK9ZH53+devzpQxdxwlM18aGExiKIMN/fj7Dw5u KDnoSrAnXEHma3uzp/WVGeMGyucf9FKPNqXhgCueZrCBzyuIzHgyOaUkwmomA+KyOwLrBAF3FblO YPZGHIGmIJCpriKb0lcv4wjUi0AzXEVa3dipl2swJbzGQJxxa7pGXTrizx1yDyHHdAYf7LiPhL5X J81frtr7inLK650q4l0ZfLfjUlK16jEuTsky9fFeWd6q2uUkpjuUb91a8xepCU0TuLu7iqx3pngG R8ARcAQcAUfAEXAEHIFsQABPL4Vt8RJTGvy3FyiBxvc6/0fDzn3s0iHjaxF3Oh/MXqL8Vt4+Y0Of SMTh5dGioFyDNFWG+jHRYVFA/U0h7uk2Bm42k24j4vI4Ao6AI+AIOAKOgCOQZQgErTkmMapdD1fM dMX8wddlzlJX+USoorzftZH4OdOhdfKe6SPo8jsCjoAj4Ag4Ao6AI+AI5AwCTt5zZqi9o46AI+AI OAKOgCPgCDgCmY6Ak/dMH0GX3xFwBBwBR8ARcAQcAUcgZxBw8p4zQ+0ddQQcAUfAEXAEHAFHwBHI dAScvGf6CGa6/PiNysvLzYuxo/+WchWH1v4YyvSfscvvCDgCjoAjsO4Q8LfmusPaW6oJASWsawrU v2suXopHpfafoM0V4KBEHhdXOYVFfn7orydHwBFwBBwBR8ARaBgCHqSpYTh5rlQg0LattH79dSm8 7TaiNaythU5Fe2lWZ2slrovffFMWvveehoPuIpsMHy6tCwsViiZEj0izvjVYnIoKqdxuOym96CIR SHxZFMLakyPQkgh4kKaWRN/bTjsEkhCkKe361ASB0ilIk5P3JgygF0kOAms6dpT8Rx+Vdscdl5wK M7CWoGnXC+OZmAFNBvak6SKX77qrFI8bJ6ILF1m9uukVeUlHIEkIOHlPEpBeTXYg4OQ9jGM6kXc3 m8mOn1bm9gLChq13jiYIOz/CXCXuYdjbt8/R0fduOwKOgCPgCDgCjUfAyXvjMfMSjoAj4Ag4Ao6A I+AIOAKOQIsg4OS9RWD3Rh0BR8ARcAQcAUfAEcgcBDiOtXplmRQvL5XiFXrxN8eustUVOmAtv1fu Nu+Z87vJOkmDzft//yvtjjlG3a3wg8jS1KOHyDbbiKxYITJ9ukj37iJ6SFOWLhUpLRVRHEQPrcqq VVkKQN3dKh82TIpHj3ab95wc/fTstNu8p+e4uFQthICS9oI2ebJiSYn85/dT5ev5K6WobX50YCuH UvGKMhl0xBYy7LS+Ulpc0WjnEh07tJE7H50oNz0wQXbv30tuv/w46dyxbZMQdPLeJNi8UDIQyAry DjE/5BCR3r1F2rQRWbZM5O23RcaMESkpEenTR+T220X23VfkrbdEbrxRhAO6hx8uMmlSdEBzxx1F 9twzsv0+4QSR++8XmTkzGRBnRB1O3jNimHJKSCfvOTXc3tkGIGCOFaKwHJFb41xL6NvZfWiqR7hk knc3m8m12ef9TR4CPXuK3H23yL33ivziFyKHHipy1VUiDz4ocumlUTvbby8yYoTI88+LnHKKyPrr ixxxhMjTT4ucd57IvHmR5p2DuzvsIDJwYJTHkyPgCDgCjoAjkCYImKFIK2XvrfNa5ezVKk1Yc5qI kSaz08VwBBqKAJFRMfeBiD/zjMhBB4kMGSJy4YWR9xw06337RnlI+DDfe+/oIqFlb9cuIu+YDHG9 9prIk0+KzJolgkb/nHNEfvYzEXygX365yODB30kH0T///GixwF+0954cAUfAEchgBJqq0czgLmec 6BXllVJeVikVOXjR78qK9NhzcPKecT8dFzgtENAAU9VEHLMYTGAWLRL5058irfqmm0bkG0JP2mkn kTPOENljj+jzoEEiaustlZXRPhz27hBwymMPj1af/6PZZ0FwzTUiDzwgsvPOIhttJHLPPSK//rXI gQeK/OEP0T209p4cAUcgLRCAiLZWLWVH3Vlrr4t1I6b8baMmdnzfkKuoqKhB+ayuVkRq1jY6dOjQ oHKWvybQuEf7iXW1U8VDvgaZsxTva319omwiSacuvu/UqVO1zGBW4NGX02IuuxDph4DbvKffmOSM RBlt847W/F//EjnqKJEjj4w05iRIvR7CDcT+sMO+s3m/9VaRq6+ONOnXXivy5z+L/OY3IldcEZnP QNg1WJE88ojIAQeIfPmlyNSpIuPHi1xwgcjvficycqTIySdH5P2GG0QmTIja+slPIi0/Gvqbb864 +eM27xk3ZFkvcDJs3iGky5cv10fDk7LxxhvrWn2YbrBVBEL67rvv6kbba1JeXq7r90qBJCcmvt9I f+vb6GH3iRMnhrJGtKk7T3f4yjQisZXn73rrraebgUfoY6itvPjii7qxNy+0AVlObIP83fXw/OG6 SwhBJ1+cjNMG3y9SpcTHH38s77zzjqxcuVKt+tZX3cMg6dWrV7i/ShUP5P3mm2/0qM+YkIe6auvT jqqk2FPP+JTqYX0WN5B26pgzZ05o44svvgj9GDBggGy11VZh4cD92nDK+snoHcwaBJJp8+7kPWum ReZ1JKPJOy9biPhdd4m8/HJkusLh03PPFTnzTJHXXxfZbTeR008Xue8+keuvF7nsssg2/pZbRH7/ +4i4Q8Ih79tuG5H3hx+OyPtXX0WeaS6+ONLA/+UvIj//eUTe9cUW6sDkhvyffRa1DZnH5CbDkpP3 DBuwHBA3GeQdzTGkdztdmB+ih9oh8ZBQyOpNN92kP+2LAzHlM8Q0MUGAd9NnyPHHHy+/+tWv9Px7 SSC7XBBlyG/nzp0DgaY8RH5bfY6MVs9NEOx99ZD8Sy+9JN26dQtlErXd1A9Bfvzxx4PGu7i4uJpw szDgelifL/fp84tFyIIFC0I7tNdTdwYpe6Y+6/r16xe+m6mH7HfffffQxw022OB7faJ9FiDn6I7k 71QZQX8oN0GfW7fr7iULDRYKK9QrFwsc5Ia8X64mgwN1V5FFgZvV5MCPL4u7mEzy7mYzWTxRvGsp RABTF7Ttjz0mss8+IpMni0ybFhF31SAFwk3Sl2JIFkVUX1Yh6Us7JLaeOazKYsAizXKc367E8ni0 wUSG9jCt+dGPIvOZ/fcXZQop7LBX7Qg4Ao1FANKMiUyi+Qffo5m+W83i3lIvVGjhJ+tvOn698cYb 8te//jUQfzTvr6tCgIv8Z511lj42CnXz71/V5adMmRLINgsCiDxEd/PNN5f//e9/8uabb9ZYP+Wp Z7Uu/k1TbqYyLDau0jM1e6ipH+T6lVdeCe2PHTs2LDzeVq9aP9Fdv08++STAQp9YUByn3rSQEflr 6tPPVQkBwafdR3Sn8RQ9yA8+V155pVocPh3aYNHx29/+VpYsWSInnnhi2EWA6NekzW/smHh+RyAb EHDyng2j6H1oGQQwbUH7zqHVX/4yMltBM85h1UcfjWR64QWRH/9Y5J//jD5zuPWnP41MbkgPPRSV oa5XX4009TNmRFr1004T+c9/onz6Eg/16ItY32jR/8nLgVXcT2JuY+S/ZdDwVh0BR6AGBCCcNZFO yC5mMVxbbLFFINrxa8stt9Rz6z2CZn5TPUNDHkxVyI9ZCZpxNOB85vve6q4W8xwzrTHbeu7xfWL9 5N9www2DxHGNNiYwkPA77rgj2Or/XncJIfBowTfbbDPZeuut9Rz+MfLHP/4xaMrR3JNMu9+lS5cg U2J7yE+b3IeIT1Nlx2/UdPBQ9dJ1j57hOUgP/WMiRBu0dfTRR8vf//730Nd71aOXaeR9kjkCjoD+ 3hwER8ARaAYCBFoiwNCdd0b+3NGKq91mdXr//chsBvt1EsGYOGyKlp7E95TRLeGgsf/HP0T3pyOC DuHHZzwJTzTUY9p16sElpb5gg/38E0+IGpo2oyNe1BFwBNY1Anbo08xU4n8hw5i2cGHSgraavyTT rGN6QrL79pnvzM4dDTeppjasnni/MY1Brp31cPxXar43atQojSe3NJi8UAeJ/++yyy6qm3ghEHna MtMf5CaxiEhsk+/IR37KItt5ajaIjT6mOfTRLsj6JptsEnYXMBuiXuT15Ag4Ak7efQ44Ao6AI+AI OALrFAFILSQW2+8f6y7aybr7hvmIXSeddFL4fvbs2UHz3hRbbwgxduSn6w4dV7x+TFGwPV+4cGEg zvEEMUc2SPXw4cP1mM4vghb82GOPDd9hTvO+KiXIgz0/GnWTD5MdSDmyx9vj/9ju/0nNCTEjYrGB +Q3knF2F+KLDZKFOvkeDv73GywCzpuCwTgfWG3ME1hECrnlfR0B7M46AI+AIOAKOgGmlIaKffvqp bsa9Jx988EEgxPGL7zikaZrsxiJnmuoPP/wwtJFYN/Vj617TYVaIOeY2d+mB/H/obiAHZxcvXizj xo0LCw7s8H/wgx+Ez3FPNhBsDtPiTSexPx999FFYTKB9p10O82LrjglNXaQcEx4uJ+6NnQGeP5sR cPKezaPrfXMEHAFHwBFIOwQwhYHo/llN3jhQygHN+DVeXcQ+99xzwZMLBL4pBzUxP0Er/tRTT6nH 2fHfq/+/6mYWzTf54vXzfzTjkHA06dikX6NxJp7XKNFo1f/2t7/p8Z6L5Ntvv1XnWucGkm7lly1b pp5zjwx9SmyT7/6gMSkwfcFcBpeR/D+x/fhgmemNE/e0m8IuUAsj4OS9hQfAm3cEHAFHwBHIPQQg pOZLnb9ooe2C3CYjQBHkF7Mbrnj9aLvjQZYMffJjRoPGHdI+f/78cMsINn7hd9KAc5B2DpF+/vnn 6sVW3dhqMnt487BjfbB2adN807Mo2F89ZFH+M3V1iykNCUzssnr+qWd/btU4GRD9ZGCSezPNe5yN CDh5z8ZR9T5FCOB+kcNa8Sh9RDq95BJRdwapQ4l2kx0ZkH7EIhqmTniv2RFwBNYFAhBlI6MQ25ou SHddEVDrkxMiDOlF089fuzBDqemwqkVKReM/Q71eQZyxgYdsm8tLM+PBjAYyjicbI978tYOr8fb4 P21aUCryDR06NJRnoYAZDZFZLcIqf/F0g83/ddddFwI3IYNr4Osbcb+fKwisE/JufmPjYZPr8tlq DzUeXPEy/Hgpl2gDaBqMusIyJ4ZabkiIajQQ9dkb1heCmgdebVuePLhoI7GP5h0gcRLGvQfQn3g5 6jHNR65M3lr7CclVDwjBzaJuR6thZhQkCR/rGkQk/F8PQKUkoUHC+wseZLp2bX4T6tFB7r8/6gN9 wa1kY0k83h/UvZv06ZP8RUXze+g1OAJZi4AFJqopCBOkGHt0/KXjh326BmWLX7hSxHbcTGziIFEf 5esis9znamzikOgBGijuElVy3HbbbeGgKiY2U9UzFoGYXlWXtriRPPvss0PwJHy9k6y9mvqaKAOa fA6h4tudqKzYz+PzHX/3+IjHp/z9+tzDJzyHYtH08x6NR4FtbL88vyOQTQikPMKqbX3hcoofJodU OAiD31h81LLith+7kXCIKG6iONzCQ42tO0gwNnL4f8U3rWkSGAy0F0R/4yHAQyHxgUW0Nx4URJ+j bh5OlEGzwIPIQkzbwCIzMqJ9wNcuCa1BPFmkOw7scBDHQlBbHuTFHy7topmgvD1sLSQ0fZ87d24I CY2GAf+3/fv3D75u8W2LnNYXsIHUc3399dehTR5y4ISMlONUPgTe3Iml+0RNWYRV9YyghpkReYbw qkZHHQyL+j4TdZ8g6jxYZL/9RN0dJB8ijWwYoqyifWeRoOPT5KTzIciqNqTBHzw+mXWM9U33navJ hlSOTBrkJPiBP+qotIvC6hFWGzKInmddIpCsCKs814lEig9z/KFbhNWbb75ZLrjggvAe4pleW4RV 3gXPaGwIbNN51vPuQGFE1NHr9fnyskZ3HjJkiGBrbkoi6iQfmm3eiwQ94n3SmPeCyfSQPncg1by/ OVzLO4m6eA9ziBWvMrx3LMLqDjvsIKeeemo45Iqtfl1EnncV7RBhFT/vHKDlXY8tPe9s/L3vqlGn L7zwwuA3nvo8OQKZjEAyI6ymlLybxp2HDzZrRGLDX2xXJVX84FlNH6EBbngg8CPnh8wPGhJO5Dmi q7FdRhns8/gxQ74PO+ywEGEO7TNl2WLD7dR+EDJNkGAjyshAe4SRxm/trzUaJYd4qO/aa68Nn3nY URcE3AJqEByDhyRt4R6L+3ECbzaKyP/ss8+G++b+izroCw8gZEFDgfbCCD550bDcoiHuZ2k4e7Yf eTiy00BYax5UPLDoD/2jHP2mfXze/vvf/w4POBY3LABoBy38sGHDgrYEu8TGPKhb6seQEvKuWIQA SEQc1eAiqtoRXflFxF0jEGq4vojY62EwnSTRha90PYylq6Aov7ouU5WW6ApJdE9XVP0VBUNiAaDz SI00RSOUiL6RRQ1Do7z4W9YDXnLDDaIOkEVXYFHkU+6jLVcfxroiFI1qEmnm8dvet29E9HWRqAMW +WknWqEe6gq+3tGW40OefDoHw//pn84Vuewy0Qkj6voh8g+v4dZDP6lbw6KH/rOAUPKgE0o07GH0 mUBQyKML4RCdlQWC/sYCZnqwTc4/X2Tw4EgWyqlmMNShi+0QFZbFEJjo/EtWcvKeLCS9nmQhkAzy zvsAss5BTZ7RgwYNqvaVzrsQLXZNpivWB95hvLv23nvv8G4wrTPvHoguijCUYJDpuEba3mEoy3g/ 7LnnnuF91BgtPMoi3osooVgYIC8KIxYQKM9QFvGOZJHAO4q+4qedxQSuH1G01bczQD8pbwo1FFn0 CeUUi5U+ulPIuxBZEpVnyRpnr8cRWJcIZAx554EDSWVLbHc1VyCkMj94yPidGtSGk+v3aeAZ7vGQ YfVOOGi0EvtoyHmIMVplI9YQeU6ws0pnW+8GJUo8XLjQgB944IGBvJ6vBIRVum0p8jBDDgI90Bak GbLLyXdCMBNSGu0FD1oS+XmojlayRBS5Sy+9NBDw+C6BkfeRI0eGhzALFB6iFmaahxL9JKw0stHP vfbaKzysCPXMdiA7AWgu0NDTR9pEU8PChVDX2PpB+s1u8TIlbISP/pGSLog9LwQesHgF4AXBAqmv Ej3a5AGb7g+8lJB3SKn6IQ4257qlG4hpPBHdlGil+kIKAY8g9ZB0iDgaag5f8RlSe/DBERn/v/+L gilBsiGzEH/IOBFViYTKroy+zMI9tOTqmUEHOyLrRF7VcdTJEJF+1cKpqiki0Nje6zzQGOJRXsgy shO1Vf0vh6TzXCdstBgwko4WnjrPOCMi5SwuCAyFeQ3lLSqrbnXrxI/MZTAj0gWyvl1FV38R6Yeg U5a+0x79RV5ks36xgNDfZlhMICPaL4i8BY9KwpPPyXsSQPQqkopAMsg7z21ILc92/g+5Nft13lm1 mUcmdgTCjHLLNOvUxbuVdxDvLFM6JZbjHUei3bg7x8YAZd5eTLFmZXnPxe3X431FVmRujIcc08LH D9GaXX5DzHAa0yfP6wi0FALJJO8ptXnnx82D6/+U/LDFxyl1yDumJGco8eCUOe6wzPYbAgxBhexD YDntzuobsxO07mgQCKdMfWgVsBVMPH2OpgLNMyt3u9AEQLJ/+MMfatT6RwPZtgSZhuhChC0/7bEt yLYmpjMcqEEbwOKipsSDjTYwA+Iv9fB/thCvuOKKoAVHY04/5ygBY4GBZgKbPhYobI3SJjsCLEpY nBC9jtP8hJ+mXdxzse0KjvSfLUt2LyiHFoRAGix6MMHBNRht1Wev31ITOKXtosFmEQZ579btu6Z4 kWH7jfaZBHFmpwbirLgH4g4Jh4BDaNVcK2jUKcdfiC8aaF1UBoIL2WU+sAiwyKa6eFKVWKTNx1yG cvyfqIAapESdI0cEHA2+/i5CIo+Z1ugcC6Y2Rtw5pKqLskDgdSs6mL0QxRV7fd01Cpp+iDZlkB3T GBYGRF5VLVbQzEPC2QHgL22fcILoxBSdONHiBTJPGTBj8QBRp15k1UVrSOwS6K5OWPSgfU/2YdyU Tgiv3BFoGQQsmijkOU5mzc853zfkSiTe5sqRsmi3ayPJVje9bwyRjqNF27zHWSTEZYVYx0l1vK9N cW1JP3hPxtuIK8taZgS9VUcgfRFIKXnnx9dbiQrR3SDH9gDjgTBx4sTwHYScxNYbh2KMiPIw4IfM g8Ds2M3sBJs6oryhuU40DzFtOw8Wu+w7O9AZP+TD/+0hFC9jQ2YEuK6DQebaijIWnc7qTCTRHMRh G5KFASY18T7SVzBCY8JBIaLRsRjBrAbTnH3VHIJQ1Dw4rZyVAaMRI0aE3QICaIB9Tp7MR2uO5lkX cLraicxArr46MouBnELCSRq0JJi6QKwh9ZicnHlmZFaDdhyiDNGvCgeue7uRqQgmKySIMQsF6oOw o4XX3ZWQqMsWelWhycOCAIJs7UGAucd31IH9PRp3iLIlFgosLnRhFgi+2XwiCzsK9BOzHIg25TCr YbHx2GPRDgIact3hCmY3kHLs5XUBG7ToLDj09xMwoZzOx7BQYBFDXhYx1gfIPIsBFheeHAFHwBFw BBwBR6BFEUgpeTfzE4gmCfMOTF04vIN5DFp0/k/Cpg6TGDTKkPq4CQsklLKEcuYADlpwSC1a98TV P2QWsstFPi7MbR5UbST+aAkLje07ybYwsR9Hw235+Ys8nIRHw49WG5lqCuFMHRB2ZOPCTp/ytM+B UuzlIfDsNJAg4djoo9nHTMbkMDtF+ko7tMdChu1RgmBwuJaDT9QFebf8plGxRQO7Gmj9wSUnyTua bN25CDbc2Idj8gL55XvIL4QbEgp5xmsLcxM7dL6fNEn0xJToJIwOduoYhryQeLThmL6Yp5eqLelg YoMdOfVBtiHkkF3qJFEv/zdXj7T35ZfRgkHnQdCYo+VXzxLVh2q5R2JRoGciAqlH681OArb2Oq8C +cajjc63kCD/7AKwGMakRs2xghz6mwrmOpB75huLDF0464my7w6wspNw+OERPpThYoHAooL+s8Bg EcNih89N8GARCenJEXAEHAFHwBFwBJqLQEoPrJpw5paRAylPPPFEsOvmYAqac+y3MRFBE4/dOWYz 2KKjgaYch1k4gX7aaaeF0+6QVwgrGvHDlXAQqhmzFYg/Zjbkh/jGD/BgR0cZyDD52Q2gnpv0kB92 +Ji5cDg1fqDH7BGpE5t3SHRNB1YxxcGcxeo020Rkx9yFerBvp59owzk9jyxo4LnPdzUl82ZDf/6j GlY07rjn4qCuLYZqKke/4rsJzZ0gqSyfEpt3ExjNOJpmI6FomyHNEGAOpGICAynFZIa8kGSINlpq iLmNC8SbctiNQ2bJBxGHOOt5BLXBikgxh1T5vx5wDgsFzEsg32iy1VQslINwV3kvCmKyM8BnyDg2 9ti1q1/lYMtu7VMPPulZNCAvGnEjz7SpZyBCe/rbCX3iQC226ZSjPyxGWHiwE6HzPCRdDIbdATVF C39ZnLAIwIwGzMAD2a0uyDxmN3i7oS/IQN1JSm7zniQgvZqkIZAMm/ekCeMVOQKOQFYgkDE273Zi HU0zZJqT45iLoHVHE050NTTTaL0h0BxONTMY0yibpxVMQTi8eZwe0ONgKqft8dQSN4WBOGNLTj4u CC8XB1ixOceGHDtx0+qTH5KMOUq8DIQcW3VIOWQfAl0byYbwY+aC7TptUQ/29ZgKscuA/TlmPnaQ 1ch7fQd6kMt8+eK2ErnZfSDVZr9IGbM9zEmte/znDdHFNAaNNpptCDgJzTFkGQ04JBjCCuk2Mgpp xSsN33FB+iHHEFYIOInPmM9AeLEdh/CipdczGyE/mm4IMvkgzhzuRGsNeaceLsxgyIucEHjINQRZ PS1VE3faIh/ycmCW/sS13iwosJ3XhaD+mCLZMO1BbnYD6LfZzyMf9XCxMCAfctHXN96IcCBhHkM7 LFTYaSA/39EX5OVzEol7fMj8/46AI+AIOAKOgCNQPwIp1bxDrL9U0gRJJ9ACh1dNu42m+zG1zYXs 4hP2FD3Q9zM1DyBoBaSZQ6domCGw1EN+S+bbHE39qFGjwn1cRWKCgzadBUFiol2L8AbBpT40/Fep C0C04LjxSkwWFa6m0+5xbzPIjFkLJD8x0aZp7NHes/OAJp+FBB51zJOAlaMv5KNfmN2w2GHxg7kP bT6AxldT3NbfXHJC7vGOQ+AMdiXi3gDqnwrrPkdKNe+p7o56FqrWcNMWiwE031UmYvU2j7ZbzZuC NhxNPmQZgo2ryCpzqnrrQBOOVh7Sz4IhQ5Nr3jN04LJY7No076v1t1lRoQtZT46AI+AINAYBfWx0 6thG7nx0otz0wATZvX8vuf3y46Rzx+/zxoZUm1Kbd8gsHmGO1qA5kGs+Q5qNiGOLju06Zi4QULTq 2LRzUBM7dDTa+Ge3/KZNRuOObXn8FL5po02rDim2k+scEDWXWnFQzObdzFDiJ90pY/7n6wOShQH5 +Yvc1MNnLjs4iqzcR/OOTTomMPSBvkHO7WKBg893FiGYFkHkcSt2sLrxw30kCxts/eNlwAnzHLz1 4KmG/5MnY7TvaHUzLaF1R7ON1pvLtPkN7Qd9xqRFA6iE8tjbo5FvKHGnHXYTsF/PYOLeULg8nyPQ UgjwUw1knnggbQr9cgx8DvgcaPQc6NBWlXStClQJq6bNSXiYpVTzDomEzOLLnMOc2LNj/oFGmLDP mJXgrxz3hxbYiABEmKpgD37SSSeFQ5oQeMpgXoO/djyqQJDJd5QeLEQjzeIAN4t8hz93s5mvCaO4 5h23i7irxHSmLlvyxHriQZreUzODyeoVhN2C+txkQc6x72d3gH6drK7+zM87Cwzs+nFnCW4sYui/ adDpGz7p0arTV9rDVIYDsuBCJDzugTMa/HQPJR0079rXdvgq95SzCJTrrlexxkII3m1qOQOSs+B4 x1sEAdO8X3rraHls3Aw5atgAOef4vaVSFTCVlcl49aauW2tLl96ypg4Fr9kRSC8EcFJd1KZIRj0/ Xe57cors2m8zuaMZmveUknegQ2uMP3fMOQhOhNa8mx4axLc5hPmcc84JJBYNNYSY/GiYCeJEOcxu iOyGFhmf6/iJxyPN8ccfH2zkKYfmmbr316iSV6tbQLzYNIS8X6PBdMhLsCgWEU0h7xxoxbf6VLVJ JjpqfeSdhQM7EJjE4Msen/Mc5EXbTnn82tNPzGUg9dYPFjOY32BOwwFWsAFLvsMkCX/v7HBwsJeU 7gGakHGN4pCnOBTiHQZbbvOykl6/OZcmlQjo/K1QD0llHNLlUK75zE9lm163I1APApD3AtWQXXjz k/LUhHdlvY4ERWqlGrOqOBHpiKC+I1u3biVFBfo7UjHLynGX7OQ9HYfKZcpNBOB/5cp1VpSUS78t N5S//eYE6dJEs5mUk3eGCOIJ+caEBreHRCLFpSGHVM0W3YbSyC2f0dajiYbckiC2lKG8uVTEHh0T EVwzvq4mCCwKIL3mhrG2KUIZyC8X9u5osRujqTb/79P0QCQEmzDVia4ra2vb+kh7kHDcUkLekQH5 MatBcx53TUl/2ckASyK3UoaAT/ST/hLgCRMki0rX1KAc6/QnxX609mkNHk885SwC+hD6LqiVBdHK WTS84+mAQGudhwUFefL4+Jny8JjpUlpeUWWGmL7kHd0HhH3pslXhfHmXTu2kvW7Vr3ECnw5TymVw BIK5TB6ORfTaZ+fecvZx+0SL7SakdULekcuiqBqprOswqOW3kMlWBqJOOa7EQEsQZzTa3OMwZ33k 1dxQUo78lKuvTCK+1IHW3wJKNTYEdU0hoa1/cbeV8XZpix0KiLwtIGrDpQnzoWWKuMa9ZXBPl1Zh Gpl47iFd8HM5UoKArSOLS8qkXN89jX0/pESoOirlnTD7s4Vy/p+elNWla+Tqsw6UPXfcci0XyOta Jm/PEXAE1kYAAo8KoH1bdSXeROJOjeuMvJv4jSW4lGtomYbmi0PZlDI1kfjmPtibKkdTy/kPyhFw BBwBR6BuBDBDwXyGl226G6AU6q7srLkL5PSrRklJ2Rq55aIjA3n35Ag4AtmHQEq9zdQEV1NIbkPL NDRfXK6mlEnsV0vWkYy2s29ae48cAUfAEWg+AtiMl5SWS7Fe/E3na01FuZSW6dmhqlSmpj6eHAFH IDsRWOfkPTth9F45Ao6AI+AIZCMCaN0z4cpG7L1PjoAjUDMCTt59ZjgCjoAj4Ag4Ao6AI+AIOAIZ goCT9wwZKBfTEXAEHAFHwBFwBBwBR8ARcPLuc8ARcAQcAUfAEXAEHAFHwBHIEAScvGfIQLmYjoAj 4Ag4Ao6AI+AIOAKOgJN3nwOOgCPgCDgCjoAj4Ag4Ao5AhiDg5D1DBsrFdAQcAUfAEXAEHAFHwBFw BJy8+xxwBBwBR8ARcAQcAUfAEXAEMgSBBkdYvePfk+SAwVvL7ZcfK/l5rcQDQGTICLuYjoAj4Ag4 AlmPQEFhkXw8b4GcduUjIcLqTb88TIYO7JP1/fYOOgK5iECDyftdj02SfVsHBbwAABA3SURBVHbq Lb8986AQLrqy0qO35eKE8T47Ao6AI+AIpB8C+fn5Mnf+Yrn4ltFSUq7k/bzDnbyn3zC5RI5AUhBo EHm/9t4X5P5npkiXDkXSoV2hyJpWskb/eXIEHAFHwBFwBByBlkegtYaBLa9YI8tWlkir1vly3bmH yIjBfVteMJfAEXAEko5Ag8j70xPekXuefF1KSsulvNw17kkfBa/QEXAEHAFHwBFoBgKo01q3aiX5 ujPevVNbuez0fWX7LXs2o0Yv6gg4AumKQIPIe3lFpSxaulxKy8qllf7z5Ag4Ao6AI+AIOALphwAk vl1RgXTr0kFao4735Ag4AlmHQIPIe9b12jvkCDgCjoAj4Ag4Ao6AI+AIZCAC7ioyAwfNRXYEHAFH wBFwBBwBR8ARyE0EnLzn5rh7rx0BR8ARcAQcAUfAEXAEMhABJ+8ZOGgusiPgCDgCjoAj4Ag4Ao5A biLg5D03x9177Qg4Ao6AI+AIOAKOgCOQgQg4ec/AQXORHQFHwBFwBBwBR8ARcARyE4GkeJuprKyU jz76SBYvXlyN4po1a2SDDTaQbbbZRioqKuT999+Xb775Zq37G220kWy11VYarbVSPvjgA1myZMla o0AdvXv3lg033FDeffdd+fbbb6WV+rElcS8vL6/6/ooVK4IMK1eurM5Dvi233FJop6a0cOFCmTNn jpSVlVXfLiwslH79+km7du1aZEasXr1a3nvvvdAPS/R1s802k169eoXvP/vss4AbEfUakhYtWiQl JSWy/vrry7x580I9bdq0aUjRlOZZvny5MAabb755GMt4mj17tnzxxRfq6qx1GGsuxp451adP6kN+ 2zgwr2zOIR9ybr311tK9e/eUYhOvfNWqVfLpp582asxrE6623yr96du371p9TWYH58+fH37nm266 aTKr9bocAUfAEXAEHIGcQyApmneIzuuvvy6lpaXStm3bQAz5ywv7zTffFMjH1KlTNcBTefV9yPHc uXPlnXfeCeT5jTfeCCTfylMHFwQV0k55SFS8fu5Pnz49LBoggW+99db3yieSwvgIs2D45JNP1qqT +xMnTgxttkRaunRp6BOkNd5XCP2HH34Y8OD7xiSI34wZM6rrjJPRxtST7Lws1hj3+OKJNpgH06ZN k2XLloU5YPOJvyyukp2YNyyI4gnZkIH5E5+TtD9lyhT58ssvky3GWvVRP3PeFgyNHfPahGMRV9Nv lX4le14wjz///PMgCvWnYuxSOgheuSPgCDgCjoAjkIYI5F2pqblyQdrRYA8bNixodXv27Bmu4uLi 8D1aY7SoQ4cODf+3+xCkBQsWyBZbbBFI9L777rvW/Y033lg6dOgQSBzkfP/99xe+s/Jo1NHIQ2wg tSwSaMPu87d9+/ZBWw2B7dy5cyCwllg8oI0eNGhQdRm0/K+99lqQo2PHjkFTDWlGfogc8pAg2bQN OUGDjOYS7TD5IKP0B00j+SHe4EBfO3XqFEgMCw7kQiv+1VdfyXrrrRfIE4uGr7/+OvQ13g/IJfnZ iYCA0S8wMexpj++M5HGPdhkDFlfkA2f+j0ymjadeZCsoKAjlSeyQQGiRBVzpK2USyR39pA1wpD7w pR7+T7sQ0FmzZoU66TeJPrCQoE5rK3EXAfJOfxgXtOxxHLp06RIwp+347ggyICvYgic7PfSNMUAu MAMT+s+4gTFjz9+xY8eGXZ+ioiLp2rVr9TggY+I4IAvygxW7APSVBSjjDsaURzb6zmfkYKyR23ZK kJWFI/PBcEfDjyzMJeYb5cjDfKWflGUMbMzBh3pY0BgO9AFZkJv8jCNzOJ7oP2WHDx++1m+V+cf8 BTPmOTiCHVgjI/IhG/1lh4uFOH0ige3MmTPDbwwZqIv84Ep+5iQy2kKIucEY8NtCVn479BM8wI75 yM4LZZK1aGnuM87LOwKOgCPgCDgC6YJAUsg7L3IIB4QGgsfLGTIDSRg4cGAgAtyHfEAQeNlzn5f3 rrvuGogGZAWSBWGAhHNB9LjHC/3jjz8O92mL+vnLferYZJNNwssf8gChsvLURduUh0xArOLknfz2 PXXyf7SdbO1jymGkHbmRg7YgIPSRHQWIBfVDciGMkJAXX3wxkA8IDPchYPTXSAj9IB+k9qWXXgqk lntG3ukTuEGMkJuy1AcBhMxCoMaPHx9MN15++eVApMgLrhAe6mOxA8GE/FAeokSbtDFu3LhA2iBb 9NUWNLRJPyGcaJaRiTrpJzso22677VrkHfzRTEMGacfapx36PGHChCCLjQt/wXDy5MkBMzCkX8i3 /fbbr2U2Q122ywChBpP4mNrCgnGiHu6DJcQafCCw9IuxQnb6xNx86qmngrz0Lb6gY1z5jrlj5J16 4uNgcw5sIbRgaKSVftI3CDv10vYzzzwTiCnkGdlpg4Un85x5B+kGE8aM/NT/3HPPhecCZJkyfEcZ 5jELSsxawI8Fk5Fy5hPjT7/YxaCfNjYQaeZJPDGnwNbK0w74gDPtMH+5x1yhHgh4t27dAgln7thu GL9f7tPeq6++GpoAAzAhL3UwvuQHV/rJb4QF96RJk8K40X8zA+M3zJyJy0bfmJO2YE6Xh6bL4Qg4 Ao6AI+AItCQCSTGb4SWMthTCyJY8BANyaGY0vNQhIhDB+H3IAqSB8hAB7kNAyGP50MZB9iAZkEou yOuDDz4Y8mBTj5YcwoemEZJj5SFJJAgG2t1EExpIEkSMNpGZuiEYpsnnHgQIIkIdEEE0k5DV3Xff PRAjvjeCDQaQEsjoDjvsEIgKJN3II+3xGWJIPogZixu0y7aoACvuI4thAFnjPlgZSTKbf7TpO+20 UyD2ECHkRTsLttTNBdE00xTT/oI333N/l112CfnpO4STRQyLqp133jnkQVbaiyfkoZ+UhzyCLWSN cSYvfUMmW7xB9iC+LEIGDx4cZGYXoaa6qYs6IOHxucD/IdR77rlnkJU6SSwiaA+SyPjQf8YQUo02 m3mAvMyj7bbbLvS3f//+gVBDTFkEsDhhjtg4MFaMAwsc5gfE9aGHHgomTZSlDGSdtoxggh0YkOgD +cBwwIABYe4wBswpFgjgCzaMA30xMylk43vkZBcInGxxRr2GLXnAF7wZc9pm/G3MkY8xTUzIxff8 Vm3egzNyMBbcjy9w7TP32alg7GiDPoOrLdRNnj322CP8Lsjbo0ePalytHn4r9Jd+ggFziHqon7mJ 3HaPulkIeHIEHAFHwBFwBByB7xBICnmHtPJy3nvvveWAAw4IpgYjR44M2mvItJHXffbZRw488MDq +5ATCASkAWKFyQvl7TrooINCHWbqMWLEiHCPOtBCQoIgXbRNHggDZbhPPvLUlSBTEI14e4ceemgg jSwE0BpCICBoEA4IFYdZIXaQQmSHjEJI+M5IG3KRwIXv0cxTB3XutddegdTQNqQsTpQoY99bX8Hy mGOOCcQdwsVfI7z020wXjMzzne0OWN9pz4hc/MCvyUk+voc8WXkj62hgE2UkP99RBgzMdMjK02/T YJsM4EDd5GGsSGjp+Zy4MIDIUT8LJBsbG1Pwh5hzEJldB8g8iw3mgWn3KQ/pM5MsSC5tMsdM4wzO ZhpCfuZoPHGfPtg4MK8g98hsJB/Z6StjC5FnAYHM9ntgYUCibvpvGMdJtcnMd3ETGNpHLpId1rVx MhMkm282Zrbo4XtrO3H+Uyf5hgwZUv1bQmbkQ4bEw7m24OUe2MUXwOCH/JSN42dzkrZs0Ui9dsXn APcpb31kF8KSzZe6fsN+zxFwBBwBR8ARyDUEkkLeefEa+TAyYkTDCAifIV3x+5SD6BhBMVMCXu52 2T0jpxAAtH5o7NBmQqLjeYxA8rcm0hkfYGQ2jaDl5y8yIxeED1K42267BW0viwHyoynEVIDv0USi 8aWM4WCEhe9oAw0jBAnijmkHdfN9HBuTy4gsWMXJSxwrI398F6+D7+07y8NfbKONlMWJY7yseXQx uSw/BDhOHk1OFiwvvPBC0A6DDYsg6z956qrbDi5C+qkn0Zaez2byZPPF5oONKTsu5hEGGcz7C4st djzQACMX88QSuNt847s4jolzxfpi8wLiyviDJTsIJNpiwWhtsdti5Jb+Mz9JfAe5pb2aDueaTDYv TLY4LvHxrKkP1rf4uNV0ANWwjc/3OCFHPvuMRp8Fpy0W4+3afLH5Zjs65GHO2Fw0XO1zYn7Dxuqr aT7n2kPZ++sIOAKOgCPgCNSFQFJs3nkxY+eMGQOEDG2oaUQhWWgKMaNBOxm/D3GDEEHG33777XAf swcrj50sWjm0zZAmNJ5mOoK5CuWwf4a4QeTQgtNeYoJsYUuLFjlOVCAZ2NWipaVNTB4g5pBBzEVo y+TlHmQMbawdouUzdSA3JAX5kBn73fjhWMpy0QaECHJJmxAddhbiiX6ABdpczDoMCzC2nQS+py1k RR4IJAQLTTRYoAGmftpkTKgLbSjt8h3mKsiN+Y+50URu+kW/0WTbgUrMMegbpj2JZBDyyo4EY8Zf dhhY7DAO5MWciWRnBWgX0w7kRC6wAAPbPYnjwHjRP7CNzwfmDIsl09hznx0dI4l2GJj5wtjSNsSb xRD12BzCDIs8tE074IIs1I3smMwwvixKbFeFecycYHzAnYu+0g51UQfzkvYwj6IN6mAOgTN4IDd9 B2/KUDfjCpaMCf+nL7SPfTyYkodxQBbKUD9zlASWaNmZc+SlXjP3YjHMDkU8Qc6RjbFIdIdqJJ02 uFgYQ95pl3FDRsqR7NAweDJnqZP+U4426C+4gjnJNPOYeVEP3yMr48ecY87ymXnKGJCok74xvz05 Ao6AI+AIOAKOQIRAUvy8U5HZW5uWlr+QGzNTgEDH3S9ynxezeTiBrHA/vnXP/yEpECZe+DV5noh/ D4kwcp84wJAQ2863e8hgHkiMmEKu4n7hIWBGRjE/ibu7g7RCkCAXtv0PuUz0oQ4JAh9IGSSLBFGk fdNYxuWF1Cb6eadt65v1GUIUlyfeNvVDEiHkjIPZFFse5KVt63fctIP2GQ/KGpHHfKWmxCIB3A0z FkemoY1roc2e2ogfhNTMh4wcx+unj+AWN6nh/4xh3GykJrzN2wvzh8WMzbHEOcTYQmDJTz8YNxZ4 lmqq2+Y65UyLzTzg/zbfwfrZZ58NiwrGERzoqyW+Y04xH9iJMZwS26P/tpMApnb4Oo5XvAx1kh/Z mO8Q5P322+97w2b9ru0haPOVMUVGk8/mOOXA1szC+GwHWO2AKt+ZPT/y2JhZXeaNJ54/8fdb1+/Z H+COgCPgCDgCjkCuIpA08p6rAGZbvyFuaL0hyRBS87XOocuazDCyrf/J6A8LHw644o4xvtBIRt21 1WEuHM3lIwthFl8cmvXkCDgCjoAj4Ag4AtmDgJP37BlL74kj4Ag4Ao6AI+AIOAKOQJYjkJQDq1mO kXfPEXAEHAFHwBFwBBwBR8ARSAsEnLynxTC4EI6AI+AIOAKOgCPgCDgCjkD9CDh5rx8jz+EIOAKO gCPgCDgCjoAj4AikBQJO3tNiGFwIR8ARcAQcAUfAEXAEHAFHoH4E/h9k9kTP6AWLqwAAAABJRU5E rkJggg== --_004_C5C3BB522B1DDF478AA09545169155B46D7FE7BCnkgeml507mbxchi_-- From nobody Fri Apr 25 04:34: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 B31C61A0451 for ; Fri, 25 Apr 2014 04:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 on8hzAZTUoyC for ; Fri, 25 Apr 2014 04:34:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EEF461A0187 for ; Fri, 25 Apr 2014 04:34:49 -0700 (PDT) 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 BDM32056; Fri, 25 Apr 2014 11:34:42 +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; Fri, 25 Apr 2014 12:33:56 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 12:34:41 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.41]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 19:34:32 +0800 From: Jiangyuanlong To: "christian.jacquenet@orange.com" , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" Thread-Topic: IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QAx+dPQAArkYRA= Date: Fri, 25 Apr 2014 11:34:31 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4VH6omPYcyxpK9dNFhoxZQ411Sk Subject: Re: [sfc] IPR related to draft-ietf-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, 25 Apr 2014 11:34:54 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984szxema506mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1, Section 3 addresses the architectural elements, which should be conside= red in a separate architecture document. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of christian.jacquenet@or= ange.com Sent: Friday, April 25, 2014 2:23 PM To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement WG, I'd like to second Med's comment: an IPR disclosure is a bit incongruous fo= r a document that is supposed to document a problem statement and only a pr= oblem statement. From this perspective, the current Section 3 is no less mi= splaced. Cheers, Christian. De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I'm surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3). I'm re-iterating my comment to remove section 3 from the PS draft as it see= ms this is the only part that is close to the solution part than the proble= m discussion. Cheers, Med ___________________________________________________________________________= ______________________________________________ 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_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984szxema506mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1, Section 3 addresses the architectural elements, which sho= uld be considered in a separate architecture document.

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of christian.jacquenet@orange.com
Sent: Friday, April 25, 2014 2:23 PM
To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

WG,

 

I’d like to second Med&= #8217;s comment: an IPR disclosure is a bit incongruous for a document that= is supposed to document a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplac= ed.

 

Cheers,

 

Christian.<= /p>

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0 : sfc@ietf.org
Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,=

 

When checking = the tracker, I found there is an IPR disclosure for the problem statement d= ocument:

https://datatracker.ietf.org/ipr/search/?opt= ion=3Ddocument_search&id=3Ddraft-ietf-sfc-problem-statement

 

I’m surp= rised to see such disclosure for a document that is supposed to describe on= ly problems (except section 3).

 

I’m re-i= terating my comment to remove section 3 from the PS draft as it seems this = is the only part that is close to the solution part than the problem discussion.

 

Cheers,

Med= 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques 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 conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984szxema506mbschi_-- From nobody Fri Apr 25 07:14: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 C6E661A04CD for ; Fri, 25 Apr 2014 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 oGtLl39m28gc for ; Fri, 25 Apr 2014 07:14:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B6E381A0232 for ; Fri, 25 Apr 2014 07:14:39 -0700 (PDT) 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 BGB83157; Fri, 25 Apr 2014 14:14:32 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 15:12:16 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 15:13:17 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 07:13:09 -0700 From: Lucy yong To: "Surendra Kumar (smkumar)" , Barry Greene , Sumandra Majee Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPX1ZfU8UhsrhhTUWWEhfLxMVVkZsgaEoAgAGXA4CAAGFgUA== Date: Fri, 25 Apr 2014 14:13:08 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453734BD@dfweml701-chm.china.huawei.com> References: <34A254A7-000E-4A38-B28E-70DC21F06AAD@senki.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7LSgaRCQJpL-2cHnP7x2ppVJlRI Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 14:14:44 -0000 SGkgU3VyZW5kcmEsDQoNClRoZSBwb2ludCB5b3UgZXhwcmVzc2VkIGJlbG93IGlzIHRoZSByZWFz b24gSSBkbyBub3Qgc3VwcG9ydCBhZG9wdGluZyBkcmFmdC1rdW1hci4gVGhlIGRyYWZ0IGRlc2Ny aWJlcyBhIGdlbmVyYWwgU0ZDIHVzZSBjYXNlIGluIGRhdGEgY2VudGVycywgd2hpY2ggY2FuIGJl IGRlc2NyaWJlZCBpbiBhIGdlbmVyYWwgdXNlIGNhc2UgZHJhZnQgcmVnYXJkbGVzcyBsb2NhdGlv bnMgYW5kIGhlbHAgZHJpdmluZyB0aGUgU0ZDIGFyY2hpdGVjdHVyZSByZXF1aXJlbWVudC4gDQoN ClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXJlbmRyYSBL dW1hciAoc21rdW1hcikNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNCwgMjAxNCA4OjE5IFBNDQpU bzogQmFycnkgR3JlZW5lOyBTdW1hbmRyYSBNYWplZQ0KQ2M6IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBhZG9wdGlvbiBv ZiBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxDQoNCkJhcnJ5LA0KDQpZb3VyIG9ic2Vy dmF0aW9uIGlzIGNvcnJlY3QuIFdlIGludGVudGlvbmFsbHkga2VwdCBpdCB0byBhIGhpZ2hlciBs ZXZlbCBhcyBvcHBvc2VkIHRvIGdvaW5nIGludG8gZWFjaCBvZiB0aGUgc3BlY2lmaWMgZXhhbXBs ZXMgaW4gZGV0YWlsLCBwcmltYXJpbHkgdG8ga2VlcCB0aGUgZm9jdXMgb24gZHJpdmluZyB0aGUg U0ZDIGFyY2hpdGVjdHVyZSByZXF1aXJlbWVudHMuIElmIHdlIGVudW1lcmF0ZSBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWlucywgd2Ugd2lsbCBub3Qgb25seSBoYXZlIGEgcXVpdGUgYSBsZW5ndGh5IGRy YWZ0IGJ1dCB3aWxsIGFsc28gbm90IGRlbW9uc3RyYXRlIGFueSBuZXcgcmVxdWlyZW1lbnRzLg0K DQpZb3VyIGNvbW1lbnRzIHdlbGwgbm90ZWQgYW5kIHRoYW5rIHlvdSENCg0KU3VyZW5kcmEuDQoN Ck9uIDQvMjMvMTQgNjowMiBQTSwgIkJhcnJ5IEdyZWVuZSIgPGJncmVlbmVAc2Vua2kub3JnPiB3 cm90ZToNCg0KPg0KPkkgZWNobyBTdW1hbmRyYSdzIG9ic2VydmF0aW9uLiBUaGlzIG5lZWRzIGFu b3RoZXIgc2VjdGlvbiB0byBwcm92aWRlIA0KPmNvbnRleHQsIGJ1dCB0aGUgbW9kZWwgaW4gdGhl IHVzZSBjYXNlcyBzZWN0aW9uIHdvdWxkIHdvcmsgd2l0aCBlYWNoIA0KPmNvbnRleHQuDQo+DQo+ QWRkaXRpb25hbGx5LCB0aGUgInVzZSBjYXNlcyIgc2VjdGlvbiBkb2VzIG5vdCByZWFkIGFzICJ1 c2UgY2FzZXMuIiBJdCANCj5pcyBhIHZlcnkgdXNlZnVsIHRvb2wgdG8gdXNlIGluIFNGQyBkZXNp Z24gaW4gYSBEQywgYnV0IG5vdCB3aGF0IHlvdSANCj51c3VhbGx5IHNlZSBhcyAidXNlIGNhc2Vz LiINCj4NCj4NCj5PbiBBcHIgMjQsIDIwMTQsIGF0IDc6NDQgQU0sIFN1bWFuZHJhIE1hamVlIDxT Lk1hamVlQEY1LmNvbT4gd3JvdGU6DQo+DQo+PiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIGJ1dCBJ IGhhdmUgZm9sbG93aW5nIG9ic2VydmF0aW9ucy4NCj4+IA0KPj4gICAxKSAgRGF0YWNlbnRlciBl bmNvbXBhc3NlcyBhIGxvdCBvZiBhcHBsaWNhdGlvbiBhbmQgdmFyaWVkIHZlcnRpY2FsIA0KPj5t YXJrZXQuIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBmb2N1cyBvbiB0aGUgZW50ZXJwcmlzZSBh bmQgcGVyaGFwcyANCj4+dGhlIGNsb3VkIERDIHVzZSBjYXNlcy4gU2VydmljZSBwcm92aWRlcnMg dXNlIGRhdGEgY2VudGVyIHRvbywgYnV0IHRoZSANCj4+cG9saWNpZXMgYXJlIG9mdGVuIGFwcGxp ZWQgcGVyIHN1YnNjcmliZXIgYW5kIHBlciByZXNvdXJjZSAoVVJMKSwgcGVyIA0KPj5hcHBsaWNh dGlvbi4gRW50ZXJwcmlzZSBkYXRhY2VudGVyIHBvbGljeSBtYXkgbm90IGludm9sdmUgcGVyIHVz ZXIgDQo+PnBvbGljeSAoSSB0aGluayBtb3N0IHdpbGwgbm90IGJ1dCBpdCBkb2VzIGludm9sdmUg YSBncm91cCBvZiB1c2VycykuDQo+PiANCj4+IFRoZXJlIGFyZSBsYXllcnMgb2YgQURDIGluIHRo ZSBlbnRlcnByaXNlIGluIHRoZSBmb3JtIG9mLA0KPj4gICAgTDQgZGlzdHJpYnV0aW9uICDigLni gLnigLnigLkgQURDIDEod2l0aCBhIHVuaWNhc3QgVklQMSkgW0FQUCByZXNvdXJjZV0gDQo+PuKA ueKAueKAueKAueKAuSAgQURDMiAoVklQMiA6IEFQUCByZXNvdXJjZSAyKS4gVGhlc2UgY2FuIGJl IHZpZXdlZCBhcyBzYW1lIA0KPj5pbnN0YW5jZSBvciBzb21ldGltZXMgTk9ULg0KPj4gDQo+PiAy KSBJbiB0aGUgbW9iaWxlIERDIHdoZW4gZmxvd3MgYXJlIHRocmVhZGVkIHRocnUgYSBzZXJpZXMg b2YgVkFTLCAgDQo+PnRoZQ0KPj41IHR1cGxlIHJlbWFpbiB1bmNoYW5nZWQuIFRoYXQgaXMgbm90 IHRoZSBjYXNlIGluIGVudGVycHJpc2Ugd2hlbiANCj4+dGhlcmUgaXMgYSBzZXJ2ZXIgdG8gc2Vy dmVyIGNvbW11bmljYXRpb24gb24gYmVoYWxmIG9mIGEgY2xpZW50LiAgVGhlIA0KPj5lYXN0IHdl c3QgdHJhZmZpYyBpbiBjbG91ZCBEQyBpcyBxdWl0ZSB1bnJ1bHkgc2luY2UgdGhlIGNoYW5nZXMg YXJlIA0KPj5tYWRlIG9mdGVuIGFuZCBuZXcgc2VydmljZXMgYXJlIGNyZWF0ZWQgYnkgRGV2T3Bz ICBldmVyeSBzbyBvZnRlbi4gSSANCj4+dGhpbmsgdGhpcyBpcyBhIHNpZ25pZmljYW50bHkgZGlm ZmVyZW50IGZyb20gU1AgZGF0YWNlbnRlciAod2hlcmUgDQo+PnNjYWxlIG1hdHRlcnMgYnV0IG51 bWJlciBvZiB1bmlxdWUgYXBwbGljYXRpb25zIGFyZSByZWxhdGl2ZWx5IHNtYWxsKSANCj4+YW5k IHNob3VsZCBiZSBjb3ZlcmVkIGluIGRldGFpbC4NCj4+IA0KPj4gSSB3b3VsZCByYXRoZXIgc2Vl IHRoZSBmb2N1cyBvbiBlbnRlcnByaXNlL2Nsb3VkIChjYWxsIHRoaXMNCj4+ZHJhZnQtZW50ZXJw cmlzZS3FoC4pIGFuZCBjb3ZlciB0aGUgdW5pcXVlbmVzcyBvZiB0aGF0IHBpZWNlIG9mIGxhbmQg DQo+PnRoYW4gYSBnZW5lcmljIERDLg0KPj4gDQo+PiBSZWdhcmRzLg0KPj4gDQo+PiBTdW1hbmRy YQ0KPj4gDQo+PiBGcm9tOiAiSmltIEd1aWNoYXJkIChqZ3VpY2hhcikiIDxqZ3VpY2hhckBjaXNj by5jb20+DQo+PiBEYXRlOiBGcmlkYXksIEFwcmlsIDE4LCAyMDE0IGF0IDM6MzENCj4+IFRvOiAi c2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3JnPg0KPj4gU3ViamVjdDogW3NmY10gQ2FsbCBmb3Ig YWRvcHRpb24gb2YgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMQ0KPj4gDQo+PiBEZWFy IFdHOg0KPj4gDQo+PiBUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgdHdvIHdlZWsgY2FsbCBmb3IgV0cg YWRvcHRpb24gb2YgdGhlIGRvY3VtZW50IA0KPj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWt1bWFyLXNmYy1kYy11c2UtY2FzZXMtMDEudHh0IGVuZGluZyAybmQgDQo+Pk1heSAyMDE0Lg0K Pj4gDQo+PiBQbGVhc2UgcmVzcG9uZCB0byB0aGUgU0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBz dGF0ZW1lbnRzIG9mIA0KPj5hcHByb3ZhbCBvciBkaXNhcHByb3ZhbC4NCj4+IA0KPj4gUGxlYXNl IG5vdGU6DQo+PiAJ4oKsIFRoaXMgaXMgbm90IFdHIExhc3QgQ2FsbC4gVGhlIGRvY3VtZW50IGlz IG5vdCBmaW5hbCwgYW5kIHRoZSBXRyBpcyANCj4+ZXhwZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1 bWVudMK5cyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyANCj4+dGhhdCB0aGUg Y29udGVudCBpcyBzb2xpZC4gVGhlcmVmb3JlLCBwbGVhc2UgZG9uwrl0IG9wcG9zZSBhZG9wdGlv biANCj4+anVzdCBiZWNhdXNlIHlvdSB3YW50IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50 Lg0KPj4gCeKCrCBJZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0aW9uIG9mIHRoZSBkb2N1 bWVudCwgcGxlYXNlIHN0YXRlIA0KPj55b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0 IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIA0KPj5jb25jZXJucy4NCj4+IAnigqwgSWYg eW91IGhhdmUgaXNzdWVzIHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9z ZSANCj4+aXNzdWVzIGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3QgdG8g YWRkcmVzcyB0aGVtLg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri Apr 25 07:22: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 4BFDE1A04E9 for ; Fri, 25 Apr 2014 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 kNXWkWx55uNB for ; Fri, 25 Apr 2014 07:22:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C646C1A0232 for ; Fri, 25 Apr 2014 07:22:07 -0700 (PDT) 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 BGB83878; Fri, 25 Apr 2014 14:22:00 +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; Fri, 25 Apr 2014 15:20:30 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 15:21:15 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 07:21:10 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , Changcheng Huang Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsh31kAgAAHTwCAAIP2MA== Date: Fri, 25 Apr 2014 14:21:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453734D7@dfweml701-chm.china.huawei.com> References: , <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> <4009BCE6-7F80-4E7B-854F-422B436ACB0D@cisco.com> In-Reply-To: <4009BCE6-7F80-4E7B-854F-422B436ACB0D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.130] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453734D7dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AtnCg8uEG3-99a4kYvntM4rf7rQ Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 14:22:14 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453734D7dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, There are several DC related use case drafts. What reason chairs choose dra= ft-kumar as WG? IMO: draft-kumar describes very generic SFC use case which can be captured = as general use case regardless locations. What is the purpose to adopt this= draft now? I do not support this adoption. Regards, Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, April 24, 2014 6:22 PM To: Changcheng Huang Cc: sfc@ietf.org Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Hi Chang, Thanks for you inputs. Please note however that the document *if* adopted i= s not final and the WG is fully expected to modify its content until there = is consensus that all of the major components have been addressed. Please c= ontinue to work with the authors to incorporate your suggestions if appropr= iate. Sent from my iPhone On Apr 24, 2014, at 6:56 PM, "Changcheng Huang" > wrote: I don't support the adoption of this document. I think it has not covered s= ome key aspects of datacenter. It is well known that datacenter services ca= n be provided in different levels which include IaaS, PaaS, and SaaS. This = document has not addressed use cases under these different scenarios, nor h= as it discussed the possible business relationships that may have an impact= on SFC. We have proposed recursive service in our contribution (draft-huan= g) which addresses these use cases and how they may be supported. Best regards, Chang ------------ Changcheng Huang On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_2691CE0099834E4A9C5044EEC662BB9D453734D7dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

 <= /p>

There are several DC rela= ted use case drafts. What reason chairs choose draft-kumar as WG?

 <= /p>

IMO: draft-kumar describe= s very generic SFC use case which can be captured as general use case regar= dless locations. What is the purpose to adopt this draft now?

 <= /p>

I do not support this ado= ption.

 <= /p>

Regards,

Lucy

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, April 24, 2014 6:22 PM
To: Changcheng Huang
Cc: sfc@ietf.org
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases= -01

 

Hi Chang,

 

Thanks for you inputs. Please note however that the = document *if* adopted is not final and the WG is fully expected to modify i= ts content until there is consensus that all of the major components have b= een addressed. Please continue to work with the authors to incorporate your suggestions if appropriate.=


Sent from my iPhone


On Apr 24, 2014, at 6:56 PM, "Changcheng Huang" <huang@sce.carleton.ca> wrote:=

I don't support the adoption of this document. I thi= nk it has not covered some key aspects of datacenter. It is well known that= datacenter services can be provided in different levels which include IaaS= , PaaS, and SaaS. This document has not addressed use cases under these different scenarios, nor has it discus= sed the possible business relationships that may have an impact on SFC. We = have proposed recursive service in our contribution (draft-huang) which add= resses these use cases and how they may be supported. 

 

Best regards,

 

Chang

------------

Changcheng Huang


On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Dear WG:

 

This message begins a two week call for WG adoption = of the document http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt=  ending 2nd May 2014. 

 

Please respond to the SFC mailing list with any stat= ements of approval or disapproval.

 

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 th= e content is solid. Therefore, please don’t oppose adoption just beca= use you want to see changes to its content.
  2. If you have objections to adoption of the document, please state your reaso= ns 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 them. 

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

--_000_2691CE0099834E4A9C5044EEC662BB9D453734D7dfweml701chmchi_-- From nobody Fri Apr 25 07:22: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 BA6841A0232 for ; Fri, 25 Apr 2014 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 Zks_ih8G5i-x for ; Fri, 25 Apr 2014 07:22:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 617411A04B6 for ; Fri, 25 Apr 2014 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6442; q=dns/txt; s=iport; t=1398435723; x=1399645323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zQRUnDw/ZDFTBCJtXFQ4dOq1yAPpHF4KU5ZKqII0DPI=; b=Yq1KTz3me4SYM8RbHW+geC9t2QeQbEzi4nTWJfEugfrjsAVhwSfcVGdZ vRVo2BZ+w9mtWaj9o8tWW9IQOQd/Fad3cUzkYbVLbFli/eDA1eAbFc8xW AQnTx3D1mAtdw5kQR8yD5MBxs8cNfG6ifMRijN38igQ+gr61b267GiTjh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAOFuWlOtJA2H/2dsb2JhbABZgwZPV4JlugKHOBl2FnSCJQEBAQQBAQEaBhE6CwwEAgEGAhEBAgEBAQECAiMDAgICJQsUAQIGCAIEAQ0FCYg4DYp2nBujRheBKY0FKwcEAoJpgUoEmQWSXIMxgis X-IronPort-AV: E=Sophos;i="4.97,927,1389744000"; d="scan'208";a="38706480" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 25 Apr 2014 14:22:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3PEM2o7019280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 14:22:02 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 09:22:02 -0500 From: "Surendra Kumar (smkumar)" To: Lucy yong , Barry Greene , Sumandra Majee Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPX1ZfU8UhsrhhTUWWEhfLxMVVkZsgRsMAgAEhqICAAU2wAP//jR8A Date: Fri, 25 Apr 2014 14:22:01 +0000 Message-ID: References: <34A254A7-000E-4A38-B28E-70DC21F06AAD@senki.org> <2691CE0099834E4A9C5044EEC662BB9D453734BD@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453734BD@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.3.9.131030 x-originating-ip: [10.21.82.87] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/H2JiDpz0Zu4Y9AMiZofBgDfuuNE Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 14:22:16 -0000 THVjeSwNCg0KVGhhdCBjb21tZW50IHdhcyBzcGVjaWZpY2FsbHkgaW4gdGhlIGNvbnRleHQgb2Yg ZW50ZXJwcmlzZSBEQ3MuIEl0IHN0aWxsDQpoYXMgc3BlY2lmaWMgZXhhbXBsZXMgYnV0IGRvZXMg bm90IGVudW1lcmF0ZSB0aGVtIHRvIGRlYXRoLg0KDQpSZ2RzLA0KU3VyZW5kcmEuDQoNCk9uIDQv MjUvMTQgNzoxMyBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToN Cg0KPkhpIFN1cmVuZHJhLA0KPg0KPlRoZSBwb2ludCB5b3UgZXhwcmVzc2VkIGJlbG93IGlzIHRo ZSByZWFzb24gSSBkbyBub3Qgc3VwcG9ydCBhZG9wdGluZw0KPmRyYWZ0LWt1bWFyLiBUaGUgZHJh ZnQgZGVzY3JpYmVzIGEgZ2VuZXJhbCBTRkMgdXNlIGNhc2UgaW4gZGF0YSBjZW50ZXJzLA0KPndo aWNoIGNhbiBiZSBkZXNjcmliZWQgaW4gYSBnZW5lcmFsIHVzZSBjYXNlIGRyYWZ0IHJlZ2FyZGxl c3MgbG9jYXRpb25zDQo+YW5kIGhlbHAgZHJpdmluZyB0aGUgU0ZDIGFyY2hpdGVjdHVyZSByZXF1 aXJlbWVudC4NCj4NCj5SZWdhcmRzLA0KPkx1Y3kNCj4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3VyZW5kcmEgS3VtYXINCj4oc21rdW1hcikNCj5TZW50OiBUaHVyc2RheSwgQXBy aWwgMjQsIDIwMTQgODoxOSBQTQ0KPlRvOiBCYXJyeSBHcmVlbmU7IFN1bWFuZHJhIE1hamVlDQo+ Q2M6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTog W3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0w MQ0KPg0KPkJhcnJ5LA0KPg0KPllvdXIgb2JzZXJ2YXRpb24gaXMgY29ycmVjdC4gV2UgaW50ZW50 aW9uYWxseSBrZXB0IGl0IHRvIGEgaGlnaGVyIGxldmVsDQo+YXMgb3Bwb3NlZCB0byBnb2luZyBp bnRvIGVhY2ggb2YgdGhlIHNwZWNpZmljIGV4YW1wbGVzIGluIGRldGFpbCwNCj5wcmltYXJpbHkg dG8ga2VlcCB0aGUgZm9jdXMgb24gZHJpdmluZyB0aGUgU0ZDIGFyY2hpdGVjdHVyZSByZXF1aXJl bWVudHMuDQo+SWYgd2UgZW51bWVyYXRlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5zLCB3ZSB3aWxs IG5vdCBvbmx5IGhhdmUgYSBxdWl0ZSBhDQo+bGVuZ3RoeSBkcmFmdCBidXQgd2lsbCBhbHNvIG5v dCBkZW1vbnN0cmF0ZSBhbnkgbmV3IHJlcXVpcmVtZW50cy4NCj4NCj5Zb3VyIGNvbW1lbnRzIHdl bGwgbm90ZWQgYW5kIHRoYW5rIHlvdSENCj4NCj5TdXJlbmRyYS4NCj4NCj5PbiA0LzIzLzE0IDY6 MDIgUE0sICJCYXJyeSBHcmVlbmUiIDxiZ3JlZW5lQHNlbmtpLm9yZz4gd3JvdGU6DQo+DQo+Pg0K Pj5JIGVjaG8gU3VtYW5kcmEncyBvYnNlcnZhdGlvbi4gVGhpcyBuZWVkcyBhbm90aGVyIHNlY3Rp b24gdG8gcHJvdmlkZQ0KPj5jb250ZXh0LCBidXQgdGhlIG1vZGVsIGluIHRoZSB1c2UgY2FzZXMg c2VjdGlvbiB3b3VsZCB3b3JrIHdpdGggZWFjaA0KPj5jb250ZXh0Lg0KPj4NCj4+QWRkaXRpb25h bGx5LCB0aGUgInVzZSBjYXNlcyIgc2VjdGlvbiBkb2VzIG5vdCByZWFkIGFzICJ1c2UgY2FzZXMu IiBJdA0KPj5pcyBhIHZlcnkgdXNlZnVsIHRvb2wgdG8gdXNlIGluIFNGQyBkZXNpZ24gaW4gYSBE QywgYnV0IG5vdCB3aGF0IHlvdQ0KPj51c3VhbGx5IHNlZSBhcyAidXNlIGNhc2VzLiINCj4+DQo+ Pg0KPj5PbiBBcHIgMjQsIDIwMTQsIGF0IDc6NDQgQU0sIFN1bWFuZHJhIE1hamVlIDxTLk1hamVl QEY1LmNvbT4gd3JvdGU6DQo+Pg0KPj4+IEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gYnV0IEkgaGF2 ZSBmb2xsb3dpbmcgb2JzZXJ2YXRpb25zLg0KPj4+IA0KPj4+ICAgMSkgIERhdGFjZW50ZXIgZW5j b21wYXNzZXMgYSBsb3Qgb2YgYXBwbGljYXRpb24gYW5kIHZhcmllZCB2ZXJ0aWNhbA0KPj4+bWFy a2V0LiBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgZm9jdXMgb24gdGhlIGVudGVycHJpc2UgYW5k IHBlcmhhcHMNCj4+PnRoZSBjbG91ZCBEQyB1c2UgY2FzZXMuIFNlcnZpY2UgcHJvdmlkZXJzIHVz ZSBkYXRhIGNlbnRlciB0b28sIGJ1dCB0aGUNCj4+PnBvbGljaWVzIGFyZSBvZnRlbiBhcHBsaWVk IHBlciBzdWJzY3JpYmVyIGFuZCBwZXIgcmVzb3VyY2UgKFVSTCksIHBlcg0KPj4+YXBwbGljYXRp b24uIEVudGVycHJpc2UgZGF0YWNlbnRlciBwb2xpY3kgbWF5IG5vdCBpbnZvbHZlIHBlciB1c2Vy DQo+Pj5wb2xpY3kgKEkgdGhpbmsgbW9zdCB3aWxsIG5vdCBidXQgaXQgZG9lcyBpbnZvbHZlIGEg Z3JvdXAgb2YgdXNlcnMpLg0KPj4+IA0KPj4+IFRoZXJlIGFyZSBsYXllcnMgb2YgQURDIGluIHRo ZSBlbnRlcnByaXNlIGluIHRoZSBmb3JtIG9mLA0KPj4+ICAgIEw0IGRpc3RyaWJ1dGlvbiAg4oC5 4oC54oC54oC5IEFEQyAxKHdpdGggYSB1bmljYXN0IFZJUDEpIFtBUFAgcmVzb3VyY2VdDQo+Pj7i gLnigLnigLnigLnigLkgIEFEQzIgKFZJUDIgOiBBUFAgcmVzb3VyY2UgMikuIFRoZXNlIGNhbiBi ZSB2aWV3ZWQgYXMgc2FtZQ0KPj4+aW5zdGFuY2Ugb3Igc29tZXRpbWVzIE5PVC4NCj4+PiANCj4+ PiAyKSBJbiB0aGUgbW9iaWxlIERDIHdoZW4gZmxvd3MgYXJlIHRocmVhZGVkIHRocnUgYSBzZXJp ZXMgb2YgVkFTLA0KPj4+dGhlDQo+Pj41IHR1cGxlIHJlbWFpbiB1bmNoYW5nZWQuIFRoYXQgaXMg bm90IHRoZSBjYXNlIGluIGVudGVycHJpc2Ugd2hlbg0KPj4+dGhlcmUgaXMgYSBzZXJ2ZXIgdG8g c2VydmVyIGNvbW11bmljYXRpb24gb24gYmVoYWxmIG9mIGEgY2xpZW50LiAgVGhlDQo+Pj5lYXN0 IHdlc3QgdHJhZmZpYyBpbiBjbG91ZCBEQyBpcyBxdWl0ZSB1bnJ1bHkgc2luY2UgdGhlIGNoYW5n ZXMgYXJlDQo+Pj5tYWRlIG9mdGVuIGFuZCBuZXcgc2VydmljZXMgYXJlIGNyZWF0ZWQgYnkgRGV2 T3BzICBldmVyeSBzbyBvZnRlbi4gSQ0KPj4+dGhpbmsgdGhpcyBpcyBhIHNpZ25pZmljYW50bHkg ZGlmZmVyZW50IGZyb20gU1AgZGF0YWNlbnRlciAod2hlcmUNCj4+PnNjYWxlIG1hdHRlcnMgYnV0 IG51bWJlciBvZiB1bmlxdWUgYXBwbGljYXRpb25zIGFyZSByZWxhdGl2ZWx5IHNtYWxsKQ0KPj4+ YW5kIHNob3VsZCBiZSBjb3ZlcmVkIGluIGRldGFpbC4NCj4+PiANCj4+PiBJIHdvdWxkIHJhdGhl ciBzZWUgdGhlIGZvY3VzIG9uIGVudGVycHJpc2UvY2xvdWQgKGNhbGwgdGhpcw0KPj4+ZHJhZnQt ZW50ZXJwcmlzZS3FoC4pIGFuZCBjb3ZlciB0aGUgdW5pcXVlbmVzcyBvZiB0aGF0IHBpZWNlIG9m IGxhbmQNCj4+PnRoYW4gYSBnZW5lcmljIERDLg0KPj4+IA0KPj4+IFJlZ2FyZHMuDQo+Pj4gDQo+ Pj4gU3VtYW5kcmENCj4+PiANCj4+PiBGcm9tOiAiSmltIEd1aWNoYXJkIChqZ3VpY2hhcikiIDxq Z3VpY2hhckBjaXNjby5jb20+DQo+Pj4gRGF0ZTogRnJpZGF5LCBBcHJpbCAxOCwgMjAxNCBhdCAz OjMxDQo+Pj4gVG86ICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDog W3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0w MQ0KPj4+IA0KPj4+IERlYXIgV0c6DQo+Pj4gDQo+Pj4gVGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3 byB3ZWVrIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudA0KPj4+aHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxLnR4dCBlbmRpbmcg Mm5kDQo+Pj5NYXkgMjAxNC4NCj4+PiANCj4+PiBQbGVhc2UgcmVzcG9uZCB0byB0aGUgU0ZDIG1h aWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mDQo+Pj5hcHByb3ZhbCBvciBkaXNhcHBy b3ZhbC4NCj4+PiANCj4+PiBQbGVhc2Ugbm90ZToNCj4+PiAJ4oKsIFRoaXMgaXMgbm90IFdHIExh c3QgQ2FsbC4gVGhlIGRvY3VtZW50IGlzIG5vdCBmaW5hbCwgYW5kIHRoZSBXRyBpcw0KPj4+ZXhw ZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1bWVudMK5cyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdH IGNvbnNlbnN1cw0KPj4+dGhhdCB0aGUgY29udGVudCBpcyBzb2xpZC4gVGhlcmVmb3JlLCBwbGVh c2UgZG9uwrl0IG9wcG9zZSBhZG9wdGlvbg0KPj4+anVzdCBiZWNhdXNlIHlvdSB3YW50IHRvIHNl ZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50Lg0KPj4+IAnigqwgSWYgeW91IGhhdmUgb2JqZWN0aW9u cyB0byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzdGF0ZQ0KPj4+eW91ciByZWFz b25zIHdoeSwgYW5kIGV4cGxhaW4gd2hhdCBpdCB3b3VsZCB0YWtlIHRvIGFkZHJlc3MgeW91cg0K Pj4+Y29uY2VybnMuDQo+Pj4gCeKCrCBJZiB5b3UgaGF2ZSBpc3N1ZXMgd2l0aCB0aGUgY29udGVu dCwgYnkgYWxsIG1lYW5zIHJhaXNlIHRob3NlDQo+Pj5pc3N1ZXMgYW5kIHdlIGNhbiBiZWdpbiBh IGRpYWxvZyBhYm91dCBob3cgYmVzdCB0byBhZGRyZXNzIHRoZW0uDQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0 DQo+Pj4gc2ZjQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Fri Apr 25 07:29: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 DDD1C1A026F for ; Fri, 25 Apr 2014 07:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 fmUfDUH2NVuV for ; Fri, 25 Apr 2014 07:29:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E90D1A01B3 for ; Fri, 25 Apr 2014 07:29:14 -0700 (PDT) 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 BDM45591; Fri, 25 Apr 2014 14:29:07 +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; Fri, 25 Apr 2014 15:27:27 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 15:28:13 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 07:28:00 -0700 From: Lucy yong To: "Surendra Kumar (smkumar)" , Barry Greene , Sumandra Majee Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPX1ZfU8UhsrhhTUWWEhfLxMVVkZsgaEoAgAGXA4CAAGFgUIAAeXGA//+LJFA= Date: Fri, 25 Apr 2014 14:28:00 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45373502@dfweml701-chm.china.huawei.com> References: <34A254A7-000E-4A38-B28E-70DC21F06AAD@senki.org> <2691CE0099834E4A9C5044EEC662BB9D453734BD@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_4oGduRrjidAXbk-2_WsGOO53cA Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 14:29:17 -0000 SGkgU3VyZW5kcmEsDQoNCkNvdWxkIHlvdSBwb2ludCBvdXQgd2hpY2ggZXhhbXBsZXMgaW4gZHJh ZnQta3VtYXIgaGF2ZSBhIHNwZWNpZmljIHJlcXVpcmVtZW50IHRoYXQgZHJhZnQtaGFlZmZuZXIg YW5kIGRyYWZ0LWxpdSBkbyBub3QgY292ZXI/DQoNClRoYW5rcywNCkx1Y3kNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBbbWFpbHRv OnNta3VtYXJAY2lzY28uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMjUsIDIwMTQgOToyMiBB TQ0KVG86IEx1Y3kgeW9uZzsgQmFycnkgR3JlZW5lOyBTdW1hbmRyYSBNYWplZQ0KQ2M6IEppbSBH dWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxs IGZvciBhZG9wdGlvbiBvZiBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxDQoNCkx1Y3ks DQoNClRoYXQgY29tbWVudCB3YXMgc3BlY2lmaWNhbGx5IGluIHRoZSBjb250ZXh0IG9mIGVudGVy cHJpc2UgRENzLiBJdCBzdGlsbCBoYXMgc3BlY2lmaWMgZXhhbXBsZXMgYnV0IGRvZXMgbm90IGVu dW1lcmF0ZSB0aGVtIHRvIGRlYXRoLg0KDQpSZ2RzLA0KU3VyZW5kcmEuDQoNCk9uIDQvMjUvMTQg NzoxMyBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkhp IFN1cmVuZHJhLA0KPg0KPlRoZSBwb2ludCB5b3UgZXhwcmVzc2VkIGJlbG93IGlzIHRoZSByZWFz b24gSSBkbyBub3Qgc3VwcG9ydCBhZG9wdGluZyANCj5kcmFmdC1rdW1hci4gVGhlIGRyYWZ0IGRl c2NyaWJlcyBhIGdlbmVyYWwgU0ZDIHVzZSBjYXNlIGluIGRhdGEgDQo+Y2VudGVycywgd2hpY2gg Y2FuIGJlIGRlc2NyaWJlZCBpbiBhIGdlbmVyYWwgdXNlIGNhc2UgZHJhZnQgcmVnYXJkbGVzcyAN Cj5sb2NhdGlvbnMgYW5kIGhlbHAgZHJpdmluZyB0aGUgU0ZDIGFyY2hpdGVjdHVyZSByZXF1aXJl bWVudC4NCj4NCj5SZWdhcmRzLA0KPkx1Y3kNCj4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU3VyZW5kcmEgS3VtYXINCj4oc21rdW1hcikNCj5TZW50OiBUaHVyc2RheSwgQXByaWwg MjQsIDIwMTQgODoxOSBQTQ0KPlRvOiBCYXJyeSBHcmVlbmU7IFN1bWFuZHJhIE1hamVlDQo+Q2M6 IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3Nm Y10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMQ0K Pg0KPkJhcnJ5LA0KPg0KPllvdXIgb2JzZXJ2YXRpb24gaXMgY29ycmVjdC4gV2UgaW50ZW50aW9u YWxseSBrZXB0IGl0IHRvIGEgaGlnaGVyIGxldmVsIA0KPmFzIG9wcG9zZWQgdG8gZ29pbmcgaW50 byBlYWNoIG9mIHRoZSBzcGVjaWZpYyBleGFtcGxlcyBpbiBkZXRhaWwsIA0KPnByaW1hcmlseSB0 byBrZWVwIHRoZSBmb2N1cyBvbiBkcml2aW5nIHRoZSBTRkMgYXJjaGl0ZWN0dXJlIHJlcXVpcmVt ZW50cy4NCj5JZiB3ZSBlbnVtZXJhdGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbnMsIHdlIHdpbGwg bm90IG9ubHkgaGF2ZSBhIHF1aXRlIA0KPmEgbGVuZ3RoeSBkcmFmdCBidXQgd2lsbCBhbHNvIG5v dCBkZW1vbnN0cmF0ZSBhbnkgbmV3IHJlcXVpcmVtZW50cy4NCj4NCj5Zb3VyIGNvbW1lbnRzIHdl bGwgbm90ZWQgYW5kIHRoYW5rIHlvdSENCj4NCj5TdXJlbmRyYS4NCj4NCj5PbiA0LzIzLzE0IDY6 MDIgUE0sICJCYXJyeSBHcmVlbmUiIDxiZ3JlZW5lQHNlbmtpLm9yZz4gd3JvdGU6DQo+DQo+Pg0K Pj5JIGVjaG8gU3VtYW5kcmEncyBvYnNlcnZhdGlvbi4gVGhpcyBuZWVkcyBhbm90aGVyIHNlY3Rp b24gdG8gcHJvdmlkZSANCj4+Y29udGV4dCwgYnV0IHRoZSBtb2RlbCBpbiB0aGUgdXNlIGNhc2Vz IHNlY3Rpb24gd291bGQgd29yayB3aXRoIGVhY2ggDQo+PmNvbnRleHQuDQo+Pg0KPj5BZGRpdGlv bmFsbHksIHRoZSAidXNlIGNhc2VzIiBzZWN0aW9uIGRvZXMgbm90IHJlYWQgYXMgInVzZSBjYXNl cy4iIEl0IA0KPj5pcyBhIHZlcnkgdXNlZnVsIHRvb2wgdG8gdXNlIGluIFNGQyBkZXNpZ24gaW4g YSBEQywgYnV0IG5vdCB3aGF0IHlvdSANCj4+dXN1YWxseSBzZWUgYXMgInVzZSBjYXNlcy4iDQo+ Pg0KPj4NCj4+T24gQXByIDI0LCAyMDE0LCBhdCA3OjQ0IEFNLCBTdW1hbmRyYSBNYWplZSA8Uy5N YWplZUBGNS5jb20+IHdyb3RlOg0KPj4NCj4+PiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIGJ1dCBJ IGhhdmUgZm9sbG93aW5nIG9ic2VydmF0aW9ucy4NCj4+PiANCj4+PiAgIDEpICBEYXRhY2VudGVy IGVuY29tcGFzc2VzIGEgbG90IG9mIGFwcGxpY2F0aW9uIGFuZCB2YXJpZWQgDQo+Pj52ZXJ0aWNh bCBtYXJrZXQuIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBmb2N1cyBvbiB0aGUgZW50ZXJwcmlz ZSBhbmQgDQo+Pj5wZXJoYXBzIHRoZSBjbG91ZCBEQyB1c2UgY2FzZXMuIFNlcnZpY2UgcHJvdmlk ZXJzIHVzZSBkYXRhIGNlbnRlciANCj4+PnRvbywgYnV0IHRoZSBwb2xpY2llcyBhcmUgb2Z0ZW4g YXBwbGllZCBwZXIgc3Vic2NyaWJlciBhbmQgcGVyIA0KPj4+cmVzb3VyY2UgKFVSTCksIHBlciBh cHBsaWNhdGlvbi4gRW50ZXJwcmlzZSBkYXRhY2VudGVyIHBvbGljeSBtYXkgbm90IA0KPj4+aW52 b2x2ZSBwZXIgdXNlciBwb2xpY3kgKEkgdGhpbmsgbW9zdCB3aWxsIG5vdCBidXQgaXQgZG9lcyBp bnZvbHZlIGEgZ3JvdXAgb2YgdXNlcnMpLg0KPj4+IA0KPj4+IFRoZXJlIGFyZSBsYXllcnMgb2Yg QURDIGluIHRoZSBlbnRlcnByaXNlIGluIHRoZSBmb3JtIG9mLA0KPj4+ICAgIEw0IGRpc3RyaWJ1 dGlvbiAg4oC54oC54oC54oC5IEFEQyAxKHdpdGggYSB1bmljYXN0IFZJUDEpIFtBUFAgcmVzb3Vy Y2VdIA0KPj4+4oC54oC54oC54oC54oC5ICBBREMyIChWSVAyIDogQVBQIHJlc291cmNlIDIpLiBU aGVzZSBjYW4gYmUgdmlld2VkIGFzIHNhbWUgDQo+Pj5pbnN0YW5jZSBvciBzb21ldGltZXMgTk9U Lg0KPj4+IA0KPj4+IDIpIEluIHRoZSBtb2JpbGUgREMgd2hlbiBmbG93cyBhcmUgdGhyZWFkZWQg dGhydSBhIHNlcmllcyBvZiBWQVMsIA0KPj4+dGhlDQo+Pj41IHR1cGxlIHJlbWFpbiB1bmNoYW5n ZWQuIFRoYXQgaXMgbm90IHRoZSBjYXNlIGluIGVudGVycHJpc2Ugd2hlbiANCj4+PnRoZXJlIGlz IGEgc2VydmVyIHRvIHNlcnZlciBjb21tdW5pY2F0aW9uIG9uIGJlaGFsZiBvZiBhIGNsaWVudC4g IFRoZSANCj4+PmVhc3Qgd2VzdCB0cmFmZmljIGluIGNsb3VkIERDIGlzIHF1aXRlIHVucnVseSBz aW5jZSB0aGUgY2hhbmdlcyBhcmUgDQo+Pj5tYWRlIG9mdGVuIGFuZCBuZXcgc2VydmljZXMgYXJl IGNyZWF0ZWQgYnkgRGV2T3BzICBldmVyeSBzbyBvZnRlbi4gSSANCj4+PnRoaW5rIHRoaXMgaXMg YSBzaWduaWZpY2FudGx5IGRpZmZlcmVudCBmcm9tIFNQIGRhdGFjZW50ZXIgKHdoZXJlIA0KPj4+ c2NhbGUgbWF0dGVycyBidXQgbnVtYmVyIG9mIHVuaXF1ZSBhcHBsaWNhdGlvbnMgYXJlIHJlbGF0 aXZlbHkgc21hbGwpIA0KPj4+YW5kIHNob3VsZCBiZSBjb3ZlcmVkIGluIGRldGFpbC4NCj4+PiAN Cj4+PiBJIHdvdWxkIHJhdGhlciBzZWUgdGhlIGZvY3VzIG9uIGVudGVycHJpc2UvY2xvdWQgKGNh bGwgdGhpcw0KPj4+ZHJhZnQtZW50ZXJwcmlzZS3FoC4pIGFuZCBjb3ZlciB0aGUgdW5pcXVlbmVz cyBvZiB0aGF0IHBpZWNlIG9mIGxhbmQgDQo+Pj50aGFuIGEgZ2VuZXJpYyBEQy4NCj4+PiANCj4+ PiBSZWdhcmRzLg0KPj4+IA0KPj4+IFN1bWFuZHJhDQo+Pj4gDQo+Pj4gRnJvbTogIkppbSBHdWlj aGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJAY2lzY28uY29tPg0KPj4+IERhdGU6IEZyaWRheSwg QXByaWwgMTgsIDIwMTQgYXQgMzozMQ0KPj4+IFRvOiAic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYu b3JnPg0KPj4+IFN1YmplY3Q6IFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWt1bWFy LXNmYy1kYy11c2UtY2FzZXMtMDENCj4+PiANCj4+PiBEZWFyIFdHOg0KPj4+IA0KPj4+IFRoaXMg bWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiB0aGUgZG9j dW1lbnQgDQo+Pj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWt1bWFyLXNmYy1kYy11c2Ut Y2FzZXMtMDEudHh0IGVuZGluZyAybmQgDQo+Pj5NYXkgMjAxNC4NCj4+PiANCj4+PiBQbGVhc2Ug cmVzcG9uZCB0byB0aGUgU0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIA0K Pj4+YXBwcm92YWwgb3IgZGlzYXBwcm92YWwuDQo+Pj4gDQo+Pj4gUGxlYXNlIG5vdGU6DQo+Pj4g CeKCrCBUaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwuIFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWws IGFuZCB0aGUgV0cgDQo+Pj5pcyBleHBlY3RlZCB0byBtb2RpZnkgdGhlIGRvY3VtZW50wrlzIGNv bnRlbnQgdW50aWwgdGhlcmUgaXMgV0cgDQo+Pj5jb25zZW5zdXMgdGhhdCB0aGUgY29udGVudCBp cyBzb2xpZC4gVGhlcmVmb3JlLCBwbGVhc2UgZG9uwrl0IG9wcG9zZSANCj4+PmFkb3B0aW9uIGp1 c3QgYmVjYXVzZSB5b3Ugd2FudCB0byBzZWUgY2hhbmdlcyB0byBpdHMgY29udGVudC4NCj4+PiAJ 4oKsIElmIHlvdSBoYXZlIG9iamVjdGlvbnMgdG8gYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50LCBw bGVhc2Ugc3RhdGUgDQo+Pj55b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0IGl0IHdv dWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIA0KPj4+Y29uY2VybnMuDQo+Pj4gCeKCrCBJZiB5b3Ug aGF2ZSBpc3N1ZXMgd2l0aCB0aGUgY29udGVudCwgYnkgYWxsIG1lYW5zIHJhaXNlIHRob3NlIA0K Pj4+aXNzdWVzIGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3QgdG8gYWRk cmVzcyB0aGVtLg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0K PnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQoNCg== From nobody Fri Apr 25 10:15: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 565DD1A06AD for ; Fri, 25 Apr 2014 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.172 X-Spam-Level: X-Spam-Status: No, score=-7.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 csgKWEBmLh0j for ; Fri, 25 Apr 2014 10:15:22 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 294E61A06AA for ; Fri, 25 Apr 2014 10:15:22 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 25 Apr 2014 10:15:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,928,1389772800"; d="scan'208,217";a="519824927" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 25 Apr 2014 10:14:44 -0700 Received: from orsmsx115.amr.corp.intel.com ([169.254.10.2]) by ORSMSX107.amr.corp.intel.com ([169.254.1.113]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 10:14:44 -0700 From: "Jani, Nrupal" To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: thought for the possible new requirement Thread-Index: Ac9f2FK/kM9cxMQFTOi94coBmqw9VAAcp4WAABc3JPA= Date: Fri, 25 Apr 2014 17:14:43 +0000 Message-ID: <096DE3A060628644893976A610FDE6F26C29F6A0@ORSMSX115.amr.corp.intel.com> References: <096DE3A060628644893976A610FDE6F26C29EFCF@ORSMSX115.amr.corp.intel.com> <94C682931C08B048B7A8645303FDC9F36F58B45191@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B45191@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_096DE3A060628644893976A610FDE6F26C29F6A0ORSMSX115amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9Ueun7CQkzfiaR9HE3X-AEQGeho Subject: Re: [sfc] thought for the possible new requirement 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, 25 Apr 2014 17:15:28 -0000 --_000_096DE3A060628644893976A610FDE6F26C29F6A0ORSMSX115amrcor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Yes, this is one of the items I had in mind. What I thinking was that inf= o. from Service function instance alone may not be enough!! We need informa= tion at each SFC level to match the established SLA. Given that everything= is going on the physical or virtual wire, effective BW of a SFC could be o= ne of measurable item we could present to the user. For example SFC (FW, DPI, NAT) where these service functions are distribute= d in the DC. In this case, we know that capacity of each of these SF insta= nce but the full capacity of these functions may be used because these is C= PU overcommit issue on the system where NAT virtual appliance is running or= virtual switch is dropping packets or may be SF Node which coordinating in= teractions among the function is choking!! I think, have a system level (which includes both the SF and other ingredie= nts involved in the SFC) picture of each SFC could be a useful data. Let me know what you all think!! Thanks, Nrupal From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, April 24, 2014 11:00 PM To: Jani, Nrupal; sfc@ietf.org Subject: RE: thought for the possible new requirement Dear Nrupal, A requirement draft I'm aware of included in a previous version this requir= ement (http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#page-= 8): DISC_REQ#4: The solution SHOULD allow the dynamic discovery of additional information characterizing a Service Function, including: * The capabilities of the Service Function. * The capacity of the Service Function. For example, this information can refer to the maximum number of binding entries that can be supported by a NAT function, the maximum number of IP-in-IP tunnels that can be established, the maximum link capacity, etc. Does this text reflect what you have in mind? Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jani, Nrupal Envoy=E9 : jeudi 24 avril 2014 18:15 =C0 : sfc@ietf.org Objet : [sfc] thought for the possible new requirement Hi there, First of all, I want to thank this WG for putting out great RFCs capturing = various requirements and usecases. I see possibility of one additional requirement, which is either not captur= ed or is there but not explicit, may be just the interpretation problem!! As we know SFC domain could contain multi-vendor SFs hosted in various form= factors, e.g. Virtual Machine, Linux Container, Bare-Metal or Physical App= liance. Additionally traffic passes through the combination of SW & HW Swi= tches, where there could be a packet loss due to various reasons. While RFCs are calling out OAM, diagnostic and elasticity related requireme= nts and SLA related usacases, I see a need to provide real-time effective B= W for given SFC. It can be useful for runtime provisioning of SFC instance= s (i.e. elasticity) of a given SFC, or to migrate SF instances to an approp= riate SF node!! For the initial thought, SF Node could be a better entity to provide real-t= ime information of each SFC chains, given that it is the anchor point in SF= C related traffic. Or could be some other ways!! Furthermore not related to requirement, but like TPCC perf. matrix from var= ious server platform vendors, having upfront perf. matrix from appliance ve= ndor for a given form factor (i.e. Virtual Machine, Linux Container, Bare-M= etal or Physical Appliance) could help admin initial provisioning of a give= n SFC. Thanks, Nrupal. --_000_096DE3A060628644893976A610FDE6F26C29F6A0ORSMSX115amrcor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Yes,  this is one= of the items I had in mind.  What I thinking was that info. from Serv= ice function instance alone may not be enough!! We need information at each= SFC level to match the established SLA.  Given that everything is going on the physical or virtual wire, effective BW of = a SFC could be one of measurable item we could present to the user.

 

For example SFC (FW, D= PI, NAT) where these service functions are distributed in the DC.  In = this case, we know that capacity of each of these SF instance but the full = capacity of these functions may be used because these is CPU overcommit issue on the system where NAT virtual appliance is= running or virtual switch is dropping packets or may be SF Node which coor= dinating interactions among the function is choking!!

 

I think, have a system= level (which includes both the SF and other ingredients involved in the SF= C) picture of each SFC could be a useful data.

 

Let me know what you a= ll think!!

 

Thanks,

 

Nrupal

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, April 24, 2014 11:00 PM
To: Jani, Nrupal; sfc@ietf.org
Subject: RE: thought for the possible new requirement

 

Dear Nrupal,

 

A requirement draft I’m aware of inclu= ded in a previous version this requirement (http://tools.ietf.org/ht= ml/draft-boucadair-sfc-requirements-03#page-8):

 

   DISC_REQ#4:  The solution SHOULD allow t= he dynamic discovery of

         &nbs= p;      additional information characterizing a Se= rvice

         &nbs= p;      Function, including:

 

         &nbs= p;      *  The capabilities of the Service Fu= nction.

 

         &nbs= p;      *  The capacity of the Service Functi= on.  For example,

         &nbs= p;         this information can ref= er to the maximum number of

         &nbs= p;         binding entries that can= be supported by a NAT

          &nb= sp;        function, the maximum nu= mber of IP-in-IP tunnels that

         &nbs= p;         can be established, the = maximum link capacity, etc.

 

Does this text reflect what you have in mind= ?

 

Cheers,

Med

 

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Jani, Nrupal
Envoy=E9 : jeudi 24 avril 2014 18:15
=C0 : sfc@ietf.org
Objet : [sfc] thought for the possible new requirement

 

Hi there,

 

First of all, I want to thank this WG for putting ou= t great RFCs capturing various requirements and usecases. 

 

I see possibility of one additional requirement, whi= ch is either not captured or is there but not explicit, may be just the int= erpretation problem!!

 

As we know SFC domain could contain multi-vendor SFs= hosted in various form factors, e.g. Virtual Machine, Linux Container, Bar= e-Metal or Physical Appliance.  Additionally traffic passes through th= e combination of SW & HW Switches, where there could be a packet loss due to various reasons.

 

While RFCs are calling out OAM, diagnostic and elast= icity related requirements and SLA related usacases, I see a need to provid= e real-time effective BW for given SFC.  It can be useful for runtime = provisioning of SFC instances (i.e. elasticity) of a given SFC, or to migrate SF instances to an appropriate SF node!!

 

For the initial thought, SF Node could be a better e= ntity to provide real-time information of each SFC chains, given that it is= the anchor point in SFC related traffic.   Or could be some othe= r ways!!

 

Furthermore not related to requirement, but like TPC= C perf. matrix from various server platform vendors, having upfront perf. m= atrix from appliance vendor for a given form factor (i.e. Virtual Machine, = Linux Container, Bare-Metal or Physical Appliance) could help admin initial provisioning of a given SFC.

 

Thanks,

 

Nrupal.

 

 

 

--_000_096DE3A060628644893976A610FDE6F26C29F6A0ORSMSX115amrcor_-- From nobody Fri Apr 25 13:15: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 1AB911A068E for ; Fri, 25 Apr 2014 13:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 tz4I58M_6BCt for ; Fri, 25 Apr 2014 13:15:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F05251A068A for ; Fri, 25 Apr 2014 13:15:35 -0700 (PDT) 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 BDM63694; Fri, 25 Apr 2014 20:15:28 +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; Fri, 25 Apr 2014 21:14:41 +0100 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; Fri, 25 Apr 2014 21:15:25 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 13:15:13 -0700 From: Linda Dunbar To: Lucy yong , "Jim Guichard (jguichar)" , Changcheng Huang Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsh31kAgAAHTwCAAIP2MIAAW6sg Date: Fri, 25 Apr 2014 20:15:13 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CFDA11@dfweml701-chm.china.huawei.com> References: , <9994C1E8-DE3C-480E-8D7B-47FBD90DFF13@sce.carleton.ca> <4009BCE6-7F80-4E7B-854F-422B436ACB0D@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453734D7@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453734D7@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.47.155.80] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645CFDA11dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XG_9FQI47HW8HJw6MNt1VUOjWFk Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 25 Apr 2014 20:15:43 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645CFDA11dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the examples given by the draft, like the sequence of functions need= ed for North-South traffic and the sequence of functions needed for East-We= st traffic. But my puzzle is why all traffic terminated at the ADC? Isn't this very ve= ndor specific? For North-South traffic, it also very common to have frontend WebServers to= terminate the external traffic. And there is Front-End FW and LB before th= e WebServers. Then traffic go to AppServer that again have its specific FW = and LB. Then traffic go to DB servers that have their specific FW (a.k.a. b= ackend FW) and LB. There are many examples of Service Function Chain in DC environment. The SF= C WG use cases should focus on the ones that can drive specific requirement= . I can't see how the examples listed in Section 3 drive the requirement list= ed in Section 5. The requirement listed in Section 5 are so general, that y= ou don't need those examples listed in Section 3. I think the key requirement driven by examples in Section 3 is to allow tho= se Service Functions to be located anywhere (i.e. not necessarily on the d= ata path). Therefore, the key requirement is allow dynamic steering policie= s to Service Nodes, routers, and switches. Therefore, I don't support this draft to be adopted to WG draft. Linda Dunbar From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Friday, April 25, 2014 9:21 AM To: Jim Guichard (jguichar); Changcheng Huang Cc: sfc@ietf.org Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Hi Jim, There are several DC related use case drafts. What reason chairs choose dra= ft-kumar as WG? IMO: draft-kumar describes very generic SFC use case which can be captured = as general use case regardless locations. What is the purpose to adopt this= draft now? I do not support this adoption. Regards, Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, April 24, 2014 6:22 PM To: Changcheng Huang Cc: sfc@ietf.org Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Hi Chang, Thanks for you inputs. Please note however that the document *if* adopted i= s not final and the WG is fully expected to modify its content until there = is consensus that all of the major components have been addressed. Please c= ontinue to work with the authors to incorporate your suggestions if appropr= iate. Sent from my iPhone On Apr 24, 2014, at 6:56 PM, "Changcheng Huang" > wrote: I don't support the adoption of this document. I think it has not covered s= ome key aspects of datacenter. It is well known that datacenter services ca= n be provided in different levels which include IaaS, PaaS, and SaaS. This = document has not addressed use cases under these different scenarios, nor h= as it discussed the possible business relationships that may have an impact= on SFC. We have proposed recursive service in our contribution (draft-huan= g) which addresses these use cases and how they may be supported. Best regards, Chang ------------ Changcheng Huang On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645CFDA11dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like the examples given= by the draft, like the sequence of functions needed for North-South traffi= c and the sequence of functions needed for East-West traffic.

 <= /p>

But my puzzle is  wh= y all traffic terminated at the ADC? Isn’t this very vendor specific?

 <= /p>

For North-South traffic, = it also very common to have frontend WebServers to terminate the external t= raffic. And there is Front-End FW and LB before the WebServers. Then traffic go to AppServer that again have its specific FW and LB. Then = traffic go to DB servers that have their specific FW (a.k.a. backend FW) an= d LB.

 <= /p>

There are many examples o= f Service Function Chain in DC environment. The SFC WG use cases should foc= us on the ones that can drive specific requirement.

 <= /p>

I can’t see how the= examples listed in Section 3 drive the requirement listed in Section 5. Th= e requirement listed in Section 5 are so general, that you don’t need those examples listed in Section 3.

 <= /p>

I think the key requireme= nt driven by examples in Section 3 is to allow those Service Functions to b= e located  anywhere (i.e. not necessarily on the data path). Therefore, the key requirement is allow dynamic steering policies to Servi= ce Nodes, routers, and switches.

 <= /p>

Therefore, I don’t = support this draft to be adopted to WG draft.

 <= /p>

Linda Dunbar

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Friday, April 25, 2014 9:21 AM
To: Jim Guichard (jguichar); Changcheng Huang
Cc: sfc@ietf.org
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases= -01

 

Hi Jim,=

 <= /p>

There are several DC rela= ted use case drafts. What reason chairs choose draft-kumar as WG?

 <= /p>

IMO: draft-kumar describe= s very generic SFC use case which can be captured as general use case regar= dless locations. What is the purpose to adopt this draft now?

 <= /p>

I do not support this ado= ption.

 <= /p>

Regards,

Lucy

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, April 24, 2014 6:22 PM
To: Changcheng Huang
Cc: sfc@ietf.org
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases= -01

 

Hi Chang,

 

Thanks for you inputs. Please note however that the = document *if* adopted is not final and the WG is fully expected to modify i= ts content until there is consensus that all of the major components have b= een addressed. Please continue to work with the authors to incorporate your suggestions if appropriate.=


Sent from my iPhone


On Apr 24, 2014, at 6:56 PM, "Changcheng Huang" <huang@sce.carleton.ca> wrote:=

I don't support the adoption of this document. I thi= nk it has not covered some key aspects of datacenter. It is well known that= datacenter services can be provided in different levels which include IaaS= , PaaS, and SaaS. This document has not addressed use cases under these different scenarios, nor has it discus= sed the possible business relationships that may have an impact on SFC. We = have proposed recursive service in our contribution (draft-huang) which add= resses these use cases and how they may be supported. 

 

Best regards,

 

Chang

------------

Changcheng Huang


On Apr 19, 2014, at 7:31 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Dear WG:

 

This message begins a two week call for WG adoption = of the document http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt=  ending 2nd May 2014. 

 

Please respond to the SFC mailing list with any stat= ements of approval or disapproval.

 

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 th= e content is solid. Therefore, please don’t oppose adoption just beca= use you want to see changes to its content.
  2. If you have objections to adoption of the document, please state your reaso= ns 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 them. 

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

--_000_4A95BA014132FF49AE685FAB4B9F17F645CFDA11dfweml701chmchi_-- From nobody Fri Apr 25 18:22: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 3A2161A0454 for ; Fri, 25 Apr 2014 18:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 t67Y-4JOaYdD for ; Fri, 25 Apr 2014 18:21:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3D2C1A044C for ; Fri, 25 Apr 2014 18:21:54 -0700 (PDT) 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 BDM75101; Sat, 26 Apr 2014 01:21:47 +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; Sat, 26 Apr 2014 02:20:43 +0100 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 26 Apr 2014 02:21:31 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.143]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Sat, 26 Apr 2014 09:21:23 +0800 From: "Liushucheng (Will)" To: Jiangyuanlong , "christian.jacquenet@orange.com" , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" Thread-Topic: IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QAx+dPQAArkYRAAHO6UkA== Date: Sat, 26 Apr 2014 01:21:21 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com> 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_C9B5F12337F6F841B35C404CF0554ACB5FEBA91FSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/inRNi2vEMao2M3GqCdVE6dlVQxU Subject: Re: [sfc] IPR related to draft-ietf-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: Sat, 26 Apr 2014 01:21:59 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FEBA91FSZXEMA509MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1. According to what we have agreed on the charter about the PS, "This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining." The part related to explicit architecture should be merged into the archite= cture document. Regards, Will (Shucheng LIU) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Friday, April 25, 2014 7:35 PM To: christian.jacquenet@orange.com; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement +1, Section 3 addresses the architectural elements, which should be conside= red in a separate architecture document. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of christian.jacquenet@or= ange.com Sent: Friday, April 25, 2014 2:23 PM To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement WG, I'd like to second Med's comment: an IPR disclosure is a bit incongruous fo= r a document that is supposed to document a problem statement and only a pr= oblem statement. From this perspective, the current Section 3 is no less mi= splaced. Cheers, Christian. De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I'm surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3). I'm re-iterating my comment to remove section 3 from the PS draft as it see= ms this is the only part that is close to the solution part than the proble= m discussion. Cheers, Med ___________________________________________________________________________= ______________________________________________ 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_C9B5F12337F6F841B35C404CF0554ACB5FEBA91FSZXEMA509MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1.

 

According to what we h= ave agreed on the charter about the PS,

 “This docu= ment will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.”= ;

The part related to ex= plicit architecture should be merged into the architecture document.

 

Regards,

Will (Shucheng LIU)

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong
Sent: Friday, April 25, 2014 7:35 PM
To: christian.jacquenet@orange.com; BOUCADAIR Mohamed IMT/OLN; sfc@i= etf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

+= 1, Section 3 addresses the architectural elements, which should be consider= ed in a separate architecture document.

=  

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of chris= tian.jacquenet@orange.com
Sent: Friday, April 25, 2014 2:23 PM
To: BOUCADAIR Mohamed IMT/OLN; sfc@i= etf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

WG,

 

I’d like to second Med’s comment= : an IPR disclosure is a bit incongruous for a document that is supposed to= document a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplaced.

 

Cheers,

 

Christian.

 

De = : sfc [mailt= o:sfc-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0 : sfc@ietf.org
Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,

 

When checking the tracker, I = found there is an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_= search&id=3Ddraft-ietf-sfc-problem-statement

 

I’m surprised to see su= ch disclosure for a document that is supposed to describe only problems (ex= cept section 3).

 

I’m re-iterating my com= ment to remove section 3 from the PS draft as it seems this is the only par= t that is close to the solution part than the problem discussion.

 

Cheers,

Med

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete 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_C9B5F12337F6F841B35C404CF0554ACB5FEBA91FSZXEMA509MBSchi_-- From nobody Fri Apr 25 18:55: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 7D0AA1A034A for ; Fri, 25 Apr 2014 18:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 iZ_muxiU_LF6 for ; Fri, 25 Apr 2014 18:55:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9652D1A0309 for ; Fri, 25 Apr 2014 18:55:25 -0700 (PDT) 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 BGC15633; Sat, 26 Apr 2014 01:55:18 +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; Sat, 26 Apr 2014 02:54:30 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 26 Apr 2014 02:55:16 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.62]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Sat, 26 Apr 2014 09:55:09 +0800 From: "Hongyu Li (Julio)" To: "Surendra Kumar (smkumar)" , Lucy yong , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of SFC use case documents Thread-Index: AQHPW1K8K2mTLR48uE+GohTdExdCc5sX9OdggAVYz0CABBg5gIABx+hw Date: Sat, 26 Apr 2014 01:55:09 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9F66A5@SZXEMA509-MBX.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@dfweml701-chm.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E9F312A@SZXEMA509-MBX.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.66.114.234] Content-Type: multipart/alternative; boundary="_000_6EB34CB5D82C4645B826C56144826EA97E9F66A5SZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tC_JHxHxUmS1f3M1uaEDe2jrDrc Subject: Re: [sfc] Progression of SFC use case documents 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, 26 Apr 2014 01:55:29 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97E9F66A5SZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 YW5kIHRoYXQgY2FuIHdvcmsgZGlyZWN0bHkgd2l0aCB0aGUgYXBwbGljYWJsZSBTRE9zIG9uIGlu Y29ycG9yYXRpbmcgcmVsZXZhbnQgY29udGVudC4NClRoZXJlIHdhcyBhIHF1ZXN0aW9uIG9uIHRo ZSBtYWlsaW5nIGxpc3QgYXNraW5nIHdoYXQgYXJlIHRoZSBTRE9zIGRyYWZ0LWt1bWFyLXNmYy1k Yy11c2UtY2FzZSBpcyBjb3JyZXNwb25kaW5nIHRvLCBidXQgbm8gYW5zd2VyIHdhcyBwb3N0ZWQg c28gZmFyLg0KU0s+IERvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgYW4gU0RPIGZvciBlbnRl cnByaXNlIERDID8NCg0KW0hMXSBZb3XigJl2ZSBqdXN0IGFza2VkIGEgYnJpbGxpYW50IHF1ZXN0 aW9uIHRvIHRoZSBjaGFpcnMsIHdobyBpcyBleHBlY3RpbmcgZHJhZnQta3VtYXItc2ZjLWRjLXVz ZS1jYXNlIGNhbiBzZXJ2ZSB0aGUgcHVycG9zZSBvZiDigJx3b3JrIGRpcmVjdGx5IHdpdGggdGhl IGFwcGxpY2FibGUgU0RPcyBvbiBpbmNvcnBvcmF0aW5nIHJlbGV2YW50IGNvbnRlbnTigJ0uDQoN Cg0KRnJvbTogU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5j b21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDI1LCAyMDE0IDg6NDEgQU0NClRvOiBIb25neXUgTGkg KEp1bGlvKTsgTHVjeSB5b25nOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3NmY10gUHJvZ3Jlc3Npb24gb2YgU0ZDIHVzZSBjYXNlIGRvY3VtZW50 cw0KDQpJbmxpbmUuDQoNCkZyb206ICJIb25neXUgTGkgKEp1bGlvKSIgPGhvbmd5dS5saUBodWF3 ZWkuY29tPG1haWx0bzpob25neXUubGlAaHVhd2VpLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJp bCAyMiwgMjAxNCAxOjU4IEFNDQpUbzogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxt YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8 amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwgInNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBQcm9ncmVzc2lvbiBvZiBTRkMgdXNlIGNhc2UgZG9j dW1lbnRzDQoNCkhpIENoYWlycywNCg0KSSBzdXBwb3J0IEx1Y3nigJlzIGNvbW1lbnQuIGRyYWZ0 LWt1bWFyLXNmYy1kYy11c2UtY2FzZSBoYXMgYSBmYW5jeSBuYW1lLCBidXQgbm90IHNvIGZhbmN5 IHVzZSBjYXNlcy4gU25pcHBlZCBmcm9tIENoYWlyc+KAmSBlbWFpbDoNClNLPiBPdXIgZ29hbCBp cyB0byBjYXB0dXJlIHRoZSB1c2UgY2FzZXMgaW4gZW50ZXJwcmlzZSBEQ3MgdGhhdCBoaWdobGln aHQgdGhlIGNoYWxsZW5nZXMgaW4gZGVwbG95aW5nIGxlZ2FjeSBzZXJ2aWNlIGNoYWluaW5nIGFu ZCBicmluZyBvdXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgU0ZDIGFyY2hpdGVjdHVyZSB3aXRoIGV4 YW1wbGVzLg0KMS4gICAgICBBZG9wdCBhIHNtYWxsIG51bWJlciBvZiBXRyBkb2N1bWVudHMgKGlu aXRpYWxseSAyKSB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIHNwZWNpZmljIGVudmlyb25tZW50cyBh bmQgdGhhdCBjYW4gYmUgd29ya2VkIG9uIGluZGVwZW5kZW50bHkgYnkgbWVtYmVycyBvZiB0aGUg V0cgdGhhdCBoYXZlIHRoZSBuZWNlc3NhcnkgZXhwZXJ0aXNlIGZvciB0aGF0IGVudmlyb25tZW50 LA0KQm90aCBtb2JpbGUgYW5kIGZpeGVkIG5ldHdvcmsgbWF5IHB1dCB0aGVpciBTZXJ2aWNlIEZ1 bmN0aW9ucyBpbiBhIHZpcnR1YWwgZW52aXJvbm1lbnQsIHdoaWNoIGlzIHZlcnkgcG9zc2libHkg IGEgZGF0YWNlbnRlci4gU28sIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZSBoYXMgYSBncmVh dCBvdmVybGFwIHdpdGggb3RoZXIgdXNlIGNhc2UgZHJhZnRzIGluY2x1ZGluZywgZXZlbiB0aG91 Z2ggeW91IHdhbnQgdG8gaGF2ZSDigJxzcGVjaWZpYyBlbnZpcm9ubWVudHPigJ0gYW5kIGNsZWFu IGN1dHMgYmV0d2VlbiB0aGVtLg0KU0s+IEluIGZhY3QgSSB3b3VsZCBnbyBhIHN0ZXAgZnVydGhl ciBhbmQgc2F5LCB0aGUgY29uY2VwdHMgdW5kZXJseWluZyBhbGwgb2YgdGhlbSBhcmUgdGhlIHNh bWUgLSB0aGUgcmVhc29uIGFsbCB1c2UgY2FzZXMgYXJlIGluIHRoaXMgV0cuIFRoZSByZXF1aXJl bWVudHMgb24gdGhlIG90aGVyIGhhbmQgYXJlIGluZGVlZCBkaWZmZXJlbnQsIHNwZWNpZmljYWxs eSB3aGVuIGNvbnRyYXN0ZWQgd2l0aCBNb2JpbGUgU1AuDQpBbHRob3VnaCBORlYgaXMgc2hpbmlu ZyBzb21lIGxpZ2h0IG9uIFNGQyB0aHJvdWdoIE1vYmlsaXR5IHVzZSBjYXNlcyBpbiByZWNlbnQg ZGF5cywgZW50ZXJwcmlzZSB1c2UgY2FzZXMgaGF2ZSBleGlzdGVkIGZvciBhIHZlcnkgbG9uZyB0 aW1lLiBUaGVyZSBhcmUgYSBsb3QgbW9yZSBlbnRlcnByaXNlIGRlcGxveW1lbnRzLCBzbWFsbCAm IGxhcmdlLCB0aGFuIG1vYmlsZSBTUC4gV2Ugd291bGQgYmUgYmV0dGVyIHNlcnZlZCBieSBub3Qg aWdub3JpbmcgdGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIFNGQyBkZXBsb3ltZW50cywgaW4gbWFq b3IgZW50ZXJwcmlzZSBEQ3MsIHByZXR0eSBtdWNoIGV2ZXJ5d2hlcmUuDQoNCmFuZCB0aGF0IGNh biB3b3JrIGRpcmVjdGx5IHdpdGggdGhlIGFwcGxpY2FibGUgU0RPcyBvbiBpbmNvcnBvcmF0aW5n IHJlbGV2YW50IGNvbnRlbnQuDQpUaGVyZSB3YXMgYSBxdWVzdGlvbiBvbiB0aGUgbWFpbGluZyBs aXN0IGFza2luZyB3aGF0IGFyZSB0aGUgU0RPcyBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2Ug aXMgY29ycmVzcG9uZGluZyB0bywgYnV0IG5vIGFuc3dlciB3YXMgcG9zdGVkIHNvIGZhci4NClNL PiBEbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9yIGFuIFNETyBmb3IgZW50ZXJwcmlzZSBEQyA/ DQoNClN1cmVuZHJhLg0KDQpTbywgaXQgc2VlbXMgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNl IGRvZXNu4oCZdCBzZXJ2ZSB5b3VyIHB1cnBvc2UgYXQgYWxsLg0KDQpCUiwNCkhvbmd5dQ0KDQpG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kg eW9uZw0KU2VudDogU2F0dXJkYXksIEFwcmlsIDE5LCAyMDE0IDc6MDYgQU0NClRvOiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3NmY10gUHJvZ3Jlc3Npb24gb2YgU0ZDIHVzZSBjYXNlIGRvY3VtZW50cw0KDQpE ZWFyIENoYWlycywNCg0KUGVvcGxlIGluY2x1ZGluZyBteXNlbGYgZGlkIG5vdCB2b2ljZSBhIHNp bmdsZSBkb2N1bWVudCB0byBjYXB0dXJlIGFsbCBwb3NzaWJsZSB1c2UgY2FzZXMgYmVjYXVzZSB0 aGVyZSBpcyBubyBuZWVkIHRvIGRvIHRoYXQuIFdlIHN1Z2dlc3RlZCBjYXB0dXJpbmcgYWxsIG5l Y2Vzc2FyeSB1c2UgY2FzZXMgdGhhdCBoZWxwIGRyaXZpbmcgdGhlIGFyY2hpdGVjdHVyZSBhbmQg cmVxdWlyZW1lbnQgZGV2ZWxvcG1lbnQuDQoNCkdpdmluZyB0aGUgc2l0dWF0aW9uLCBJIHN1cHBv cnQgYWRvcHRpbmcgZHJhZnQtaGFlZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmxpdHkgYXMgV0cgZHJh ZnQuIFRoaXMgaXMgYmVjYXVzZSBhIGxhcmdlIHBvcnRpb24gb2YgU0ZDIHVzZSBjYXNlcyBhcmUg aW4gTW9iaWxlIGFwcGxpY2F0aW9uczsgYW5kIHRoZSBkcmFmdCBkZXNjcmliZXMgbWFueSB1bmlx dWUgd2F5cyB0byB1c2UgU0ZDLiBJdCBpcyBnb29kIHRvIGhhdmUgb25lIGRyYWZ0IHRvIGNvdmVy IE1vYmlsZSBhcmVhLg0KDQpJTU86IGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZXMgZG9lcyBu b3QgZGVwaWN0IHVuaXF1ZSBTRkMgY2FzZXMgZnJvbSBhIGdlbmVyYWwgU0ZDIGNhc2UgZXhjZXB0 IHRoZSBTRkMgYXBwbGljYXRpb25zIGxvY2F0aW9uIGlzIGluIGRhdGEgY2VudGVycy4gVGh1cyB0 aGVzZSBjYXNlcyBjYW4gYmUgZWFzaWx5IG1lcmdlZCBpbnRvIHRoZSBnZW5lcmFsIHVzZSBjYXNl IGRyYWZ0LiBTbyB3ZSBoYXZlIGFub3RoZXIgdXNlIGNhc2UgZHJhZnQgZm9yIHRoZSByZXN0Lg0K DQpSZWdhcmRzLA0KTHVjeQ0KDQpEZWFyIFdHOg0KDQpUaGVyZSBoYXMgYmVlbiBtdWNoIGRpc2N1 c3Npb24gYm90aCBvbiB0aGUgbGlzdCBhbmQgZHVyaW5nIG91ciBmYWNlLXRvLWZhY2UgbWVldGlu Z3MgYWJvdXQgaG93IGJlc3QgdG8gcHJvZ3Jlc3MgdXNlIGNhc2UgZG9jdW1lbnRzIHdpdGhpbiB0 aGUgV0cuIFRoZXJlIGFyZSBjbGVhcmx5IGFyZ3VtZW50cyBmb3IgYm90aCBvZiB0aGUgZm9sbG93 aW5nIGFwcHJvYWNoZXM6DQoNCiAgMS4gIEEgc2luZ2xlIGRvY3VtZW50IHRoYXQgY2FwdHVyZXMg YWxsIG9mIHRoZSBwb3NzaWJsZSB1c2UgY2FzZXMuDQogIDIuICBBIHNtYWxsIG51bWJlciBvZiB0 YXJnZXRlZCBkb2N1bWVudHMgdGhhdCBhcmUgZm9jdXNlZCBvbiBhIHBhcnRpY3VsYXIgc3Vic2V0 IG9mIHRoZSBvdmVyYWxsIHByb2JsZW0gc3BhY2UgKHN1Y2ggYXMgYnJvYWRiYW5kLCBtb2JpbGl0 eSwgYW5kIGRhdGEgY2VudGVyKS4NCkJ1dCwgd2UgY2Fu4oCZdCBjaG9vc2UgYm90aC4gSW4gY29u c2lkZXJpbmcgdGhlc2UgYXBwcm9hY2hlcywgdGhlIGNoYWlycyByZWNvZ25pemUgdGhhdCB0aGVy ZSBhcmUgYmVuZWZpdHMgdG8gaGF2aW5nIGEgc2luZ2xlIGRvY3VtZW50LCBidXQgZG8gbm90IGJl bGlldmUgaGF2aW5nIGp1c3Qgb25lIGRvY3VtZW50IGlzIHdvcmthYmxlIGluIHRoaXMgY2FzZS4g Tm9yIGlzIHRoZXJlIGNvbnNlbnN1cyBmb3IgaGF2aW5nIGEgc2luZ2xlIGRvY3VtZW50LiAgVGhl cmVmb3JlLCB3ZSB3aWxsIHB1cnN1ZSB0aGUgZm9sbG93aW5nIGFwcHJvYWNoIGdvaW5nIGZvcndh cmQ6DQoNCiAgMS4gIEFkb3B0IGEgc21hbGwgbnVtYmVyIG9mIFdHIGRvY3VtZW50cyAoaW5pdGlh bGx5IDIpIHRoYXQgYXJlIGFwcGxpY2FibGUgdG8gc3BlY2lmaWMgZW52aXJvbm1lbnRzIGFuZCB0 aGF0IGNhbiBiZSB3b3JrZWQgb24gaW5kZXBlbmRlbnRseSBieSBtZW1iZXJzIG9mIHRoZSBXRyB0 aGF0IGhhdmUgdGhlIG5lY2Vzc2FyeSBleHBlcnRpc2UgZm9yIHRoYXQgZW52aXJvbm1lbnQsIGFu ZCB0aGF0IGNhbiB3b3JrIGRpcmVjdGx5IHdpdGggdGhlIGFwcGxpY2FibGUgU0RPcyBvbiBpbmNv cnBvcmF0aW5nIHJlbGV2YW50IGNvbnRlbnQuDQogIDIuICBDb250aW51ZSB0byBsZWF2ZSBvcGVu IHRoZSBwb3NzaWJpbGl0eSBvZiBhZG9wdGluZyBhIGhpZ2gtbGV2ZWwgdXNlIGNhc2UgZG9jdW1l bnQgdGhhdCBzZXJ2ZXMgYXMgYSDigJxjYXRjaCBhbGzigJ0gZm9yIHVzZSBjYXNlcyB0aGF0IGRv IG5vdCBtZXJpdCB0aGVpciBvd24gZG9jdW1lbnQgb3IgYXJlIG5vdCBjYXB0dXJlZCBpbiB0aGUg Y29udGVudCBvZiBtb3JlIGZvY3VzZWQgdXNlIGNhc2UgZG9jdW1lbnRzLiBIb3dldmVyLCBiZWZv cmUgdGFraW5nIG9uIHN1Y2ggYSBkb2N1bWVudCwgdGhlIFdHIHdpbGwgbmVlZCB0byB1bmRlcnN0 YW5kIGluIG1vcmUgZGV0YWlsIHdoYXQgdGhlIGNvbnRlbnQgd291bGQgYmUgYW5kIHRoYXQgdGhl IGNvbnRlbnQganVzdGlmaWVzIGhhdmluZyBzdWNoIGEgZG9jdW1lbnQuIFN1Y2ggYSBkb2N1bWVu dCBzaG91bGQgbm90IGR1cGxpY2F0ZSBtYXRlcmlhbCB0aGF0IGlzIGNvdmVyZWQgaW4gb3RoZXIg ZG9jdW1lbnRzLg0KVG8gZmFjaWxpdGF0ZSB0aGUgYWJvdmUgZGlyZWN0aW9uIHRoZSBjaGFpcnMg d2lsbCB0YWtlIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQoNCiAgMS4gIENhbGwgZm9yIHRoZSBhZG9w dGlvbiBvZiBkcmFmdC1oYWVmZm5lci1zZmMtdXNlLWNhc2UtbW9ibGl0eSBhbmQgZHJhZnQta3Vt YXItc2ZjLWRjLXVzZS1jYXNlcyBhcyBXRyBkb2N1bWVudHMuDQogIDIuICBFbmNvdXJhZ2UgdGhl IGF1dGhvcnMgdG8gY29udGludWUgdG8gd29yayBvbiByZWZpbmVtZW50IG9mIGRyYWZ0LWxpdS1z ZmMtdXNlLWNhc2VzLiBUaGUgYXV0aG9ycyBvZiB0aGF0IGRvY3VtZW50IHNob3VsZCB1cGRhdGUg dGhlaXIgZHJhZnQgdG8gcmVtb3ZlIGFueSBkdXBsaWNhdGlvbiBvZiBtYXRlcmlhbCBjb3ZlcmVk IGluIG90aGVyIGRvY3VtZW50cyBhcyB3ZWxsIGFzIGlkZW50aWZ5IGNvbnRlbnQgdGhhdCBpcyBu b3QgY292ZXJlZCBlbHNld2hlcmUuDQpXZSBob3BlIHRoYXQgdGhpcyBhcHByb2FjaCB3aWxsIGFs bG93IHRoZSBXRyB0byBtb3ZlIGZvcndhcmQgYW5kIGFsc28gcHJvdmlkZSBlbm91Z2ggZmxleGli aWxpdHkgdG8gYWxsb3cgdXNlIGNhc2VzIHRvIGV2b2x2ZSBpbmRlcGVuZGVudGx5LCB3aXRoIGRp cmVjdCBpbnRlcmFjdGlvbiB3aXRoIHRoZSBhcHByb3ByaWF0ZSBTRE9zLg0KDQpUaGFua3MsDQoN CkppbSAmIFRob21hcw0K --_000_6EB34CB5D82C4645B826C56144826EA97E9F66A5SZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiXDYyNzlcNkNFOFw2ODQ2XDY1 ODdcNjcyQyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5h bWU6Ilw2Mjc5XDZDRThcNjg0Nlw2NTg3XDY3MkMgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOlw2Mjc5XDZDRThcNjg0Nlw2NTg3XDY3MkM7DQoJZm9udC1m YW1pbHk6U2ltU3VuO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNjAzMjUxNjI7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjYzNjI0NjA3Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w OjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6Mzc3MzE3NjIyOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczo5NjYxMTAxNjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOjM2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6NDc2NTM0NjQzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxMzY1MjU1MDcyO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjU4 MTY0ODMwNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTY1MTQxNzg5Njt9DQpAbGlzdCBsNA0K CXttc28tbGlzdC1pZDo1OTc0NDc0NDI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc5OTQzMjE4 ODt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDo2NDEyMjcyODk7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0yMDg0NjU3NDk4O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2 ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsNg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3Rv cDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE3Ljg1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPmFuZCB0aGF0IGNhbiB3b3JrIGRpcmVjdGx5IHdpdGggdGhl IGFwcGxpY2FibGUgU0RPcyBvbiBpbmNvcnBvcmF0aW5nIHJlbGV2YW50IGNvbnRlbnQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgd2FzIGEgcXVlc3Rpb24gb24gdGhlIG1h aWxpbmcgbGlzdCBhc2tpbmcgd2hhdCBhcmUgdGhlIFNET3MgZHJhZnQta3VtYXItc2ZjLWRjLXVz ZS1jYXNlIGlzIGNvcnJlc3BvbmRpbmcgdG8sIGJ1dCBubyBhbnN3ZXIgd2FzIHBvc3RlZCBzbw0K IGZhci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlNLJmd0OyBEbyB5b3UgaGF2ZSBhIHN1 Z2dlc3Rpb24gZm9yIGFuIFNETyBmb3IgZW50ZXJwcmlzZSBEQyA/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSExdIFlvdeKAmXZlIGp1c3QgYXNrZWQgYSBicmlsbGlh bnQgcXVlc3Rpb24gdG8gdGhlIGNoYWlycywgd2hvIGlzIGV4cGVjdGluZw0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZHJhZnQt a3VtYXItc2ZjLWRjLXVzZS1jYXNlIGNhbiBzZXJ2ZSB0aGUgcHVycG9zZSBvZiDigJw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+d29y aw0KIGRpcmVjdGx5IHdpdGggdGhlIGFwcGxpY2FibGUgU0RPcyBvbiBpbmNvcnBvcmF0aW5nIHJl bGV2YW50IGNvbnRlbnTigJ0uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikgW21haWx0bzpzbWt1 bWFyQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDI1LCAyMDE0 IDg6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IEhvbmd5dSBMaSAoSnVsaW8pOyBMdWN5IHlvbmc7IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtzZmNdIFByb2dyZXNzaW9uIG9mIFNGQyB1c2UgY2FzZSBkb2N1bWVudHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOnJlZCI+SW5saW5lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZxdW90 O0hvbmd5dSBMaSAoSnVsaW8pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aG9uZ3l1LmxpQGh1 YXdlaS5jb20iPmhvbmd5dS5saUBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgQXByaWwgMjIsIDIwMTQgMTo1OCBBTTxicj4NCjxiPlRvOiA8L2I+THVjeSB5b25n ICZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3 ZWkuY29tPC9hPiZndDssICZxdW90O0ppbSBHdWljaGFyZCAoamd1aWNoYXIpJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFByb2dyZXNzaW9uIG9mIFNGQyB1 c2UgY2FzZSBkb2N1bWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBDaGFpcnMsPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBzdXBwb3J0IEx1Y3nigJlzIGNvbW1lbnQuIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZSBo YXMgYSBmYW5jeSBuYW1lLCBidXQgbm90IHNvIGZhbmN5IHVzZSBjYXNlcy4gU25pcHBlZCBmcm9t IENoYWlyc+KAmSBlbWFpbDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlNLJmd0OyBPdXIgZ29hbCBp cyB0byBjYXB0dXJlIHRoZSB1c2UgY2FzZXMgaW4gZW50ZXJwcmlzZSBEQ3MgdGhhdCBoaWdobGln aHQgdGhlIGNoYWxsZW5nZXMgaW4gZGVwbG95aW5nIGxlZ2FjeSBzZXJ2aWNlIGNoYWluaW5nIGFu ZCBicmluZyBvdXQgdGhlIHJlcXVpcmVtZW50cw0KIGZvciBTRkMgYXJjaGl0ZWN0dXJlIHdpdGgg ZXhhbXBsZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS43cHQ7dGV4dC1pbmRl bnQ6LTE3Ljg1cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7bGF5b3V0LWdyaWQtbW9kZTpjaGFy Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BZG9wdCBhIHNtYWxsIG51bWJl ciBvZiBXRyBkb2N1bWVudHMgKGluaXRpYWxseSAyKSB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIHNw ZWNpZmljIGVudmlyb25tZW50cyBhbmQgdGhhdCBjYW4gYmUgd29ya2VkIG9uIGluZGVwZW5kZW50 bHkNCiBieSBtZW1iZXJzIG9mIHRoZSBXRyB0aGF0IGhhdmUgdGhlIG5lY2Vzc2FyeSBleHBlcnRp c2UgZm9yIHRoYXQgZW52aXJvbm1lbnQsIDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Qm90aCBtb2JpbGUgYW5kIGZpeGVkIG5ldHdvcmsgbWF5IHB1dCB0aGVpciBTZXJ2aWNlIEZ1 bmN0aW9ucyBpbiBhIHZpcnR1YWwgZW52aXJvbm1lbnQsIHdoaWNoIGlzIHZlcnkgcG9zc2libHkg Jm5ic3A7YSBkYXRhY2VudGVyLiBTbywgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlDQogaGFz IGEgZ3JlYXQgb3ZlcmxhcCB3aXRoIG90aGVyIHVzZSBjYXNlIGRyYWZ0cyBpbmNsdWRpbmcsIGV2 ZW4gdGhvdWdoIHlvdSB3YW50IHRvIGhhdmUg4oCcc3BlY2lmaWMgZW52aXJvbm1lbnRz4oCdIGFu ZCBjbGVhbiBjdXRzIGJldHdlZW4gdGhlbS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlNLJmd0OyBJ biBmYWN0IEkgd291bGQgZ28gYSBzdGVwIGZ1cnRoZXIgYW5kIHNheSwgdGhlIGNvbmNlcHRzIHVu ZGVybHlpbmcgYWxsIG9mIHRoZW0gYXJlIHRoZSBzYW1lIC0gdGhlIHJlYXNvbiBhbGwgdXNlIGNh c2VzIGFyZSBpbiB0aGlzIFdHLiBUaGUgcmVxdWlyZW1lbnRzDQogb24gdGhlIG90aGVyIGhhbmQg YXJlIGluZGVlZCBkaWZmZXJlbnQsIHNwZWNpZmljYWxseSB3aGVuIGNvbnRyYXN0ZWQgd2l0aCBN b2JpbGUgU1AuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 cmVkIj5BbHRob3VnaCBORlYgaXMgc2hpbmluZyBzb21lIGxpZ2h0IG9uIFNGQyB0aHJvdWdoIE1v YmlsaXR5IHVzZSBjYXNlcyBpbiByZWNlbnQgZGF5cywgZW50ZXJwcmlzZSB1c2UgY2FzZXMgaGF2 ZSBleGlzdGVkIGZvciBhIHZlcnkgbG9uZyB0aW1lLiBUaGVyZQ0KIGFyZSBhIGxvdCBtb3JlIGVu dGVycHJpc2UgZGVwbG95bWVudHMsIHNtYWxsICZhbXA7IGxhcmdlLCB0aGFuIG1vYmlsZSBTUC4g V2Ugd291bGQgYmUgYmV0dGVyIHNlcnZlZCBieSBub3QgaWdub3JpbmcgdGhlIHZhc3QgbWFqb3Jp dHkgb2YgdGhlIFNGQyBkZXBsb3ltZW50cywgaW4gbWFqb3IgZW50ZXJwcmlzZSBEQ3MsIHByZXR0 eSBtdWNoIGV2ZXJ5d2hlcmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNy44NXB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5hbmQgdGhhdCBjYW4gd29yayBk aXJlY3RseSB3aXRoIHRoZSBhcHBsaWNhYmxlIFNET3Mgb24gaW5jb3Jwb3JhdGluZyByZWxldmFu dCBjb250ZW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIHdhcyBhIHF1 ZXN0aW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QgYXNraW5nIHdoYXQgYXJlIHRoZSBTRE9zIGRyYWZ0 LWt1bWFyLXNmYy1kYy11c2UtY2FzZSBpcyBjb3JyZXNwb25kaW5nIHRvLCBidXQgbm8gYW5zd2Vy IHdhcyBwb3N0ZWQgc28NCiBmYXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5TSyZndDsgRG8geW91 IGhhdmUgYSBzdWdnZXN0aW9uIGZvciBhbiBTRE8gZm9yIGVudGVycHJpc2UgREMgPzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5TdXJlbmRyYS48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIGl0IHNlZW1zIGRyYWZ0LWt1bWFyLXNmYy1kYy11 c2UtY2FzZSBkb2VzbuKAmXQgc2VydmUgeW91ciBwdXJwb3NlIGF0IGFsbC48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CUiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib25neXU8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHNmYyBbPGEg aHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MdWN5IHlvbmc8YnI+DQo8Yj5TZW50Ojwv Yj4gU2F0dXJkYXksIEFwcmlsIDE5LCAyMDE0IDc6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEppbSBH dWljaGFyZCAoamd1aWNoYXIpOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBQcm9ncmVzc2lvbiBvZiBT RkMgdXNlIGNhc2UgZG9jdW1lbnRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgQ2hhaXJz LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBlb3BsZSBpbmNsdWRpbmcgbXlzZWxmIGRpZCBub3Qgdm9p Y2UgYSBzaW5nbGUgZG9jdW1lbnQgdG8gY2FwdHVyZSBhbGwgcG9zc2libGUgdXNlIGNhc2VzIGJl Y2F1c2UgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyB0aGF0LiBXZSBzdWdnZXN0ZWQNCiBjYXB0dXJp bmcgYWxsIG5lY2Vzc2FyeSB1c2UgY2FzZXMgdGhhdCBoZWxwIGRyaXZpbmcgdGhlIGFyY2hpdGVj dHVyZSBhbmQgcmVxdWlyZW1lbnQgZGV2ZWxvcG1lbnQuDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+R2l2aW5nIHRoZSBzaXR1YXRpb24sIEkgc3VwcG9ydCBhZG9w dGluZyBkcmFmdC1oYWVmZm5lci1zZmMtdXNlLWNhc2UtbW9ibGl0eSBhcyBXRyBkcmFmdC4gVGhp cyBpcyBiZWNhdXNlIGEgbGFyZ2UgcG9ydGlvbiBvZiBTRkMgdXNlIGNhc2VzDQogYXJlIGluIE1v YmlsZSBhcHBsaWNhdGlvbnM7IGFuZCB0aGUgZHJhZnQgZGVzY3JpYmVzIG1hbnkgdW5pcXVlIHdh eXMgdG8gdXNlIFNGQy4gSXQgaXMgZ29vZCB0byBoYXZlIG9uZSBkcmFmdCB0byBjb3ZlciBNb2Jp bGUgYXJlYS4NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTU86 IGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZXMgZG9lcyBub3QgZGVwaWN0IHVuaXF1ZSBTRkMg Y2FzZXMgZnJvbSBhIGdlbmVyYWwgU0ZDIGNhc2UgZXhjZXB0IHRoZSBTRkMgYXBwbGljYXRpb25z IGxvY2F0aW9uIGlzIGluIGRhdGENCiBjZW50ZXJzLiBUaHVzIHRoZXNlIGNhc2VzIGNhbiBiZSBl YXNpbHkgbWVyZ2VkIGludG8gdGhlIGdlbmVyYWwgdXNlIGNhc2UgZHJhZnQuIFNvIHdlIGhhdmUg YW5vdGhlciB1c2UgY2FzZSBkcmFmdCBmb3IgdGhlIHJlc3QuPC9zcGFuPjwvaT48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgV0c6PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVyZSBoYXMgYmVlbiBtdWNo IGRpc2N1c3Npb24gYm90aCBvbiB0aGUgbGlzdCBhbmQgZHVyaW5nIG91ciBmYWNlLXRvLWZhY2Ug bWVldGluZ3MgYWJvdXQgaG93IGJlc3QgdG8gcHJvZ3Jlc3MgdXNlIGNhc2UgZG9jdW1lbnRzIHdp dGhpbiB0aGUgV0cuDQogVGhlcmUgYXJlIGNsZWFybHkgYXJndW1lbnRzIGZvciBib3RoIG9mIHRo ZSBmb2xsb3dpbmcgYXBwcm9hY2hlczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8b2wgc3RhcnQ9IjEi IHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps NSBsZXZlbDEgbGZvNSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5BIHNpbmdsZSBkb2N1bWVudCB0aGF0IGNhcHR1cmVzIGFsbCBvZiB0aGUgcG9zc2libGUgdXNl IGNhc2VzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVsMSBsZm81 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkEgc21hbGwgbnVt YmVyIG9mIHRhcmdldGVkIGRvY3VtZW50cyB0aGF0IGFyZSBmb2N1c2VkIG9uIGEgcGFydGljdWxh ciBzdWJzZXQgb2YgdGhlIG92ZXJhbGwgcHJvYmxlbSBzcGFjZSAoc3VjaCBhcyBicm9hZGJhbmQs IG1vYmlsaXR5LCBhbmQgZGF0YSBjZW50ZXIpLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJ1dCwg d2UgY2Fu4oCZdCBjaG9vc2UgYm90aC4gSW4gY29uc2lkZXJpbmcgdGhlc2UgYXBwcm9hY2hlcywg dGhlIGNoYWlycyByZWNvZ25pemUgdGhhdCB0aGVyZSBhcmUgYmVuZWZpdHMgdG8gaGF2aW5nIGEg c2luZ2xlIGRvY3VtZW50LCBidXQgZG8gbm90DQogYmVsaWV2ZSBoYXZpbmcganVzdCBvbmUgZG9j dW1lbnQgaXMgd29ya2FibGUgaW4gdGhpcyBjYXNlLiBOb3IgaXMgdGhlcmUgY29uc2Vuc3VzIGZv ciBoYXZpbmcgYSBzaW5nbGUgZG9jdW1lbnQuICZuYnNwO1RoZXJlZm9yZSwgd2Ugd2lsbCBwdXJz dWUgdGhlIGZvbGxvd2luZyBhcHByb2FjaCBnb2luZyBmb3J3YXJkOjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkFkb3B0IGEgc21hbGwgbnVtYmVyIG9mIFdHIGRvY3VtZW50cyAo aW5pdGlhbGx5IDIpIHRoYXQgYXJlIGFwcGxpY2FibGUgdG8gc3BlY2lmaWMgZW52aXJvbm1lbnRz IGFuZCB0aGF0IGNhbiBiZSB3b3JrZWQgb24gaW5kZXBlbmRlbnRseSBieSBtZW1iZXJzIG9mIHRo ZSBXRyB0aGF0IGhhdmUgdGhlIG5lY2Vzc2FyeQ0KIGV4cGVydGlzZSBmb3IgdGhhdCBlbnZpcm9u bWVudCwgYW5kIHRoYXQgY2FuIHdvcmsgZGlyZWN0bHkgd2l0aCB0aGUgYXBwbGljYWJsZSBTRE9z IG9uIGluY29ycG9yYXRpbmcgcmVsZXZhbnQgY29udGVudC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Db250aW51ZSB0byBsZWF2ZSBvcGVuIHRoZSBwb3NzaWJpbGl0eSBv ZiBhZG9wdGluZyBhIGhpZ2gtbGV2ZWwgdXNlIGNhc2UgZG9jdW1lbnQgdGhhdCBzZXJ2ZXMgYXMg YSDigJxjYXRjaCBhbGzigJ0gZm9yIHVzZSBjYXNlcyB0aGF0IGRvIG5vdCBtZXJpdCB0aGVpciBv d24gZG9jdW1lbnQgb3IgYXJlIG5vdCBjYXB0dXJlZA0KIGluIHRoZSBjb250ZW50IG9mIG1vcmUg Zm9jdXNlZCB1c2UgY2FzZSBkb2N1bWVudHMuIEhvd2V2ZXIsIGJlZm9yZSB0YWtpbmcgb24gc3Vj aCBhIGRvY3VtZW50LCB0aGUgV0cgd2lsbCBuZWVkIHRvIHVuZGVyc3RhbmQgaW4gbW9yZSBkZXRh aWwgd2hhdCB0aGUgY29udGVudCB3b3VsZCBiZSBhbmQgdGhhdCB0aGUgY29udGVudCBqdXN0aWZp ZXMgaGF2aW5nIHN1Y2ggYSBkb2N1bWVudC4gU3VjaCBhIGRvY3VtZW50IHNob3VsZCBub3QgZHVw bGljYXRlDQogbWF0ZXJpYWwgdGhhdCBpcyBjb3ZlcmVkIGluIG90aGVyIGRvY3VtZW50cy4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UbyBmYWNpbGl0YXRlIHRoZSBhYm92ZSBkaXJlY3Rp b24gdGhlIGNoYWlycyB3aWxsIHRha2UgdGhlIGZvbGxvd2luZyBzdGVwczo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvOSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYWxsIGZvciB0aGUgYWRvcHRpb24gb2YgZHJhZnQtaGFl ZmZuZXItc2ZjLXVzZS1jYXNlLW1vYmxpdHkgYW5kIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2Fz ZXMgYXMgV0cgZG9jdW1lbnRzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm85Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkVuY291cmFnZSB0aGUgYXV0aG9ycyB0byBjb250aW51ZSB0byB3b3JrIG9uIHJlZmluZW1lbnQg b2YgZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMuIFRoZSBhdXRob3JzIG9mIHRoYXQgZG9jdW1lbnQg c2hvdWxkIHVwZGF0ZSB0aGVpciBkcmFmdCB0byByZW1vdmUgYW55IGR1cGxpY2F0aW9uIG9mIG1h dGVyaWFsIGNvdmVyZWQNCiBpbiBvdGhlciBkb2N1bWVudHMgYXMgd2VsbCBhcyBpZGVudGlmeSBj b250ZW50IHRoYXQgaXMgbm90IGNvdmVyZWQgZWxzZXdoZXJlLiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPldlIGhvcGUgdGhhdCB0aGlzIGFwcHJvYWNoIHdpbGwgYWxsb3cgdGhlIFdHIHRv IG1vdmUgZm9yd2FyZCBhbmQgYWxzbyBwcm92aWRlIGVub3VnaCBmbGV4aWJpbGl0eSB0byBhbGxv dyB1c2UgY2FzZXMgdG8gZXZvbHZlIGluZGVwZW5kZW50bHksIHdpdGgNCiBkaXJlY3QgaW50ZXJh Y3Rpb24gd2l0aCB0aGUgYXBwcm9wcmlhdGUgU0RPcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkppbSAmYW1wOyBUaG9tYXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EB34CB5D82C4645B826C56144826EA97E9F66A5SZXEMA509MBXchi_-- From nobody Sat Apr 26 09:19: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 8D2591A04C2 for ; Sat, 26 Apr 2014 09:19:36 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 inqq1f9vkxQ7 for ; Sat, 26 Apr 2014 09:19:34 -0700 (PDT) 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 64AD21A04F1 for ; Sat, 26 Apr 2014 09:19:34 -0700 (PDT) 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.0174.001; Sat, 26 Apr 2014 09:19:27 -0700 From: Ron Parker To: "Liushucheng (Will)" Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: AQHPYWtLK9fZ1WanLkWs3eNrhRUTbQ== Date: Sat, 26 Apr 2014 16:19:26 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com>, 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_BCFAF839F0914FBB9B60AB144E55D0F6affirmednetworkscom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/p1XAslLTdx5w7149n9W-n1-qT90 Cc: Jiangyuanlong , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" , "christian.jacquenet@orange.com" Subject: Re: [sfc] IPR related to draft-ietf-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: Sat, 26 Apr 2014 16:19:36 -0000 --_000_BCFAF839F0914FBB9B60AB144E55D0F6affirmednetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 Ron On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" > wrote: +1. According to what we have agreed on the charter about the PS, =93This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining.=94 The part related to explicit architecture should be merged into the archite= cture document. Regards, Will (Shucheng LIU) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Friday, April 25, 2014 7:35 PM To: christian.jacquenet@orange.com; = BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement +1, Section 3 addresses the architectural elements, which should be conside= red in a separate architecture document. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of christian.jacquenet@or= ange.com Sent: Friday, April 25, 2014 2:23 PM To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement WG, I=92d like to second Med=92s comment: an IPR disclosure is a bit incongruou= s for a document that is supposed to document a problem statement and only = a problem statement. From this perspective, the current Section 3 is no les= s misplaced. Cheers, Christian. De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I=92m surprised to see such disclosure for a document that is supposed to d= escribe only problems (except section 3). I=92m re-iterating my comment to remove section 3 from the PS draft as it s= eems this is the only part that is close to the solution part than the prob= lem discussion. Cheers, Med ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_BCFAF839F0914FBB9B60AB144E55D0F6affirmednetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1

  Ron


On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" <liushucheng@huawei.com> wrote:

+1.

 

According to what we h= ave agreed on the charter about the PS,

 =93This document= will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.=94

The part related to ex= plicit architecture should be merged into the architecture document.

 

Regards,

Will (Shucheng LIU)

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong
Sent: Friday, April 25, 2014 7:35 PM
To: christian.jacq= uenet@orange.com; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

+= 1, Section 3 addresses the architectural elements, which should be consider= ed in a separate architecture document.

=  

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of chris= tian.jacquenet@orange.com
Sent: Friday, April 25, 2014 2:23 PM
To: BOUCADAIR Mohamed IMT/OLN; sfc@i= etf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

WG,

 

I=92d like to second Med=92s comment: an IPR= disclosure is a bit incongruous for a document that is supposed to documen= t a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplaced.

 

Cheers,

 

Christian.

 

De = : sfc [mailt= o:sfc-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0 : sfc@ietf.org
Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,

 

When checking the tracker, I = found there is an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_= search&id=3Ddraft-ietf-sfc-problem-statement

 

I=92m surprised to see such d= isclosure for a document that is supposed to describe only problems (except= section 3).

 

I=92m re-iterating my comment= to remove section 3 from the PS draft as it seems this is the only part th= at is close to the solution part than the problem discussion.

 

Cheers,

Med

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete 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.
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_BCFAF839F0914FBB9B60AB144E55D0F6affirmednetworkscom_-- From nobody Sun Apr 27 15:59: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 300441A06CF for ; Sun, 27 Apr 2014 15:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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.651, 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 CLWtU5R-fvqi for ; Sun, 27 Apr 2014 15:59:01 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id C53AE1A069C for ; Sun, 27 Apr 2014 15:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4489; q=dns/txt; s=iport; t=1398639540; x=1399849140; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SdbHaMoF6npKpA/PnwFxcgDuANZ74g5996SGkxc5HGo=; b=E4OxzfCL6pufkLK26m25ScFkG1wxh9tVqd7GyrrH2VybCvCfQkxTr58n OZdZUtucfj4uZundZc+g4vV3mJBVAq2ncoNqPC+0hbMCjxKRTaeP9TkO9 lI2BhFNDIzC+Le9cvHR/2ZPsZWrnd19b+0GFQshPD48xr2AMF6DUDGKbs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FALCKXVOtJA2K/2dsb2JhbABZgkJET0sMvSsBhziBCxZ0giYBAQQBAQELD0gJCxACAQgEOwcnCxQRAgQOBQmIOA3JFBeOWQeDJIEVBJkMkl6DMYIr X-IronPort-AV: E=Sophos; i="4.97,939,1389744000"; d="scan'208,217"; a="39194579" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 27 Apr 2014 22:58:58 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3RMwwqx031864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 27 Apr 2014 22:58:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Sun, 27 Apr 2014 17:58:57 -0500 From: "Carlos Pignataro (cpignata)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsmda4A Date: Sun, 27 Apr 2014 22:58:57 +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.82.253.253] Content-Type: multipart/alternative; boundary="_000_FA5A76D5FA754901A5EF6DF0E8E89C06ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NqoA3wgPdFXRMvgVj90SGRRndKY Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 27 Apr 2014 22:59:03 -0000 --_000_FA5A76D5FA754901A5EF6DF0E8E89C06ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable SFC Chairs, I support the adoption of draft-kumar-sfc-dc-use-cases-01 as an SFC WG docu= ment. This document addresses a very important set of use cases of SFC on the DC.= The scope is relevant, and the document itself is a very comprehensive, th= orough, and clear starting point for the WG. As a starting point, I believe= the document achieves a good balance in being general enough while describ= ing specifics of the DC. Thanks, -- Carlos. On Apr 18, 2014, at 6:31 PM, Jim Guichard (jguichar) > wrote: Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_FA5A76D5FA754901A5EF6DF0E8E89C06ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable SFC Chairs,

I support the adoption of draft-kumar-sfc-dc-use-cases-01 as an S= FC WG document.

This document addresses a very important set of use cases of SFC on th= e DC. The scope is relevant, and the document itself is a very comprehensiv= e, thorough, and clear starting point for the WG. As a starting point, I be= lieve the document achieves a good balance in being general enough while describing specifics of the DC.

Thanks,

-- Carlos.

On Apr 18, 2014, at 6:31 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_FA5A76D5FA754901A5EF6DF0E8E89C06ciscocom_-- From nobody Mon Apr 28 14:56: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 E1F4D1A6FB7 for ; Mon, 28 Apr 2014 14:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 3uA_RA_iLlAF for ; Mon, 28 Apr 2014 14:55:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDD81A8836 for ; Mon, 28 Apr 2014 14:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1160; q=dns/txt; s=iport; t=1398722157; x=1399931757; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=n5PWKk5Ju5B8nkbpuQ1k/I6T/e0U0+CJvdzZdZy4Cb0=; b=EVond9fcqGQAaUgofhVC8CFupcX+nvswsDgF70ELZZ9r9ys2IvStbXlk 3Ll0M6yKPKBZH3b6UG/AwNJKXctlvPWsnjw6I/zFHtyzSPz/4Jm97P5kh m3yLYbKa/EPeu5qZyQrgdhCFJdsxw7grn6LjOQ6c5qzCNFyjNuLA4LI2i M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABXNXlOtJA2G/2dsb2JhbABZgwZPSwy9MYc5gRsWdIIlAQEBAwEBAQEaUQsFCwIBCEYnCyUCBA4FCYgwCA3IYBeOJjMHgySBFQSZDJJegzGCKw X-IronPort-AV: E=Sophos;i="4.97,946,1389744000"; d="scan'208";a="321022087" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 28 Apr 2014 21:55:57 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3SLtvIf018216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 21:55:57 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.122]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 16:55:56 -0500 From: "Darrel Lewis (darlewis)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPYyyhrYRSm0H2Z0u/3/TSuRFfeQ== Date: Mon, 28 Apr 2014 21:55:56 +0000 Message-ID: <1F233BD8-9874-4FC9-B59E-4BB79411CFE9@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.19.253.189] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jadlcCeqMxLr98e-U3sHkzRfPgg Cc: "Darrel Lewis \(darlewis\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 28 Apr 2014 21:56:00 -0000 Support, this document is a good starting place for the WG. -Darrel On Apr 18, 2014, at 3:31 PM, Jim Guichard (jguichar) w= rote: > Dear WG: >=20 > This message begins a two week call for WG adoption of the document http:= //www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014.= =20 >=20 > Please respond to the SFC mailing list with any statements of approval or= disapproval. >=20 > Please note: > =95 This is not WG Last Call. The document is not final, and the WG is e= xpected to modify the document=92s content until there is WG consensus that= the content is solid. Therefore, please don=92t oppose adoption just becau= se you want to see changes to its content. > =95 If you have objections to adoption of the document, please state you= r reasons why, and explain what it would take to address your concerns. > =95 If you have issues with the content, by all means raise those issues= and we can begin a dialog about how best to address them.=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 28 17:09: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 CA3AB1A8844 for ; Mon, 28 Apr 2014 17:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jUZW1O1jkICI for ; Mon, 28 Apr 2014 17:09:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C04B61A6F17 for ; Mon, 28 Apr 2014 17:09:08 -0700 (PDT) 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 BGE71984; Tue, 29 Apr 2014 00:09:07 +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; Tue, 29 Apr 2014 01:08:11 +0100 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Apr 2014 01:09:06 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML702-CHM.china.huawei.com ([169.254.4.52]) with mapi id 14.03.0158.001; Mon, 28 Apr 2014 17:08:59 -0700 From: Jiafeng Zhu To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsnwgkw Date: Tue, 29 Apr 2014 00:08:58 +0000 Message-ID: <7585D84250391C4F93CA91360F2AF130C6A6C3@SJCEML703-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.193.35.69] Content-Type: multipart/alternative; boundary="_000_7585D84250391C4F93CA91360F2AF130C6A6C3SJCEML703CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ugxNVjiuldOMwkik-od6ZRceh-w Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 29 Apr 2014 00:09:12 -0000 --_000_7585D84250391C4F93CA91360F2AF130C6A6C3SJCEML703CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I don't support this adoption. Although it mentions the multiple tenants s= ituation, in section 3 ... Further, enterprise data centers may be organize= d along businesses, with each business treated as a tenant, thereby support= ing multi-tenancy..., but this document doesn't clearly indicate that a te= nant can also provide services for its tenant recursively. Regards, Jiafeng Zhu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 3:32 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_7585D84250391C4F93CA91360F2AF130C6A6C3SJCEML703CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

I don’t support this  adoption. Althoug= h it mentions the multiple tenants situation, in section 3 … Further,= enterprise data centers may be organized along businesses, with each busin= ess treated as a tenant, thereby supporting multi-tenancy…,  but this document doesn’t clear= ly indicate that a tenant can also provide services fo= r its tenant recursively.

       = ;         Regards,

       = ;         Jiafeng Zhu

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 3:32 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:<= /p>

 

This message begins a two w= eek call for WG adoption of the document http://www.ietf.org/id/draft-kuma= r-sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

Please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, 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 sta= te your reasons why, and explain what it would take to address your concern= s.
  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 them. =
--_000_7585D84250391C4F93CA91360F2AF130C6A6C3SJCEML703CHMchina_-- From nobody Tue Apr 29 05:03: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 51D9C1A08C0 for ; Tue, 29 Apr 2014 05:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 PVycCDvZLayz for ; Tue, 29 Apr 2014 05:03:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4A71A08BB for ; Tue, 29 Apr 2014 05:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11797; q=dns/txt; s=iport; t=1398773006; x=1399982606; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SCa6NE9838pC93ZZEi37NzuAzETieVPMIuECDwbdWY4=; b=M3Psj0ubjYL95tO2hqIwQer2cXyVtOWgjKbv90eKWHM6LISGGe8Ki4vN 2lKTEAq9Ob/j8sdlLA/AbDnh96+UESMPyCEI9acO7S4+dgllPOXJTsfLA ykiC/HP/PWgCkzyVO2c1lcTrsnIeQqfdUyxi8J86AbDNNuDEZgc6XjlGW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFALqUX1OtJV2c/2dsb2JhbABZgkJET1fEdoEgFnSCJQEBAQQdEEEbAgEIEQMBAQEoBzIUCQgCBAESCYg4DckmF44+FwEGhDMEmRCSYoMxgis X-IronPort-AV: E=Sophos;i="4.97,951,1389744000"; d="scan'208,217";a="318112589" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 29 Apr 2014 12:03:25 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3TC3PRh020848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 12:03:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 07:03:25 -0500 From: "Jim Guichard (jguichar)" To: Jiafeng Zhu , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsnwgkwgADeFAA= Date: Tue, 29 Apr 2014 12:03:24 +0000 Message-ID: References: <7585D84250391C4F93CA91360F2AF130C6A6C3@SJCEML703-CHM.china.huawei.com> In-Reply-To: <7585D84250391C4F93CA91360F2AF130C6A6C3@SJCEML703-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.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_CF850D251FD73jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BCBj5Y_VDku8OH6J8CO5jHjCiWQ Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 29 Apr 2014 12:03:29 -0000 --_000_CF850D251FD73jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jiafeng, Please note that the omission of content is normal process and the WG is ex= pected to modify the document content until there is WG consensus that the = content is solid and complete. If you believe there is content missing plea= se have that discussion either directly with the authors or on the list so = that your concerns may be properly discussed. From: Jiafeng Zhu > Date: Monday, April 28, 2014 at 8:08 PM To: Jim Guichard >, "sfc@ietf= .org" > Subject: RE: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Hi Jim, I don=92t support this adoption. Although it mentions the multiple tenants= situation, in section 3 =85 Further, enterprise data centers may be organi= zed along businesses, with each business treated as a tenant, thereby suppo= rting multi-tenancy=85, but this document doesn=92t clearly indicate that = a tenant can also provide services for its tenant recursively. Regards, Jiafeng Zhu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, April 18, 2014 3:32 PM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF850D251FD73jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3FF65B85805D1D4098F4985698152459@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Jiafeng,

Please note that the omission of content is normal process and the WG = is expected to modify the document content until there is WG consensus that= the content is solid and complete. If you believe there is content missing= please have that discussion either directly with the authors or on the list so that your concerns may be prop= erly discussed. 

From: Jiafeng Zhu <jiafeng.Zhu@huawei.com>
Date: Monday, April 28, 2014 at 8:0= 8 PM
To: Jim Guichard <jguichar@cisco.com>, "sfc@ietf.org" <s= fc@ietf.org>
Subject: RE: Call for adoption of d= raft-kumar-sfc-dc-use-cases-01

Hi Jim,

I don=92t support this  adoption. Although it mentions the mul= tiple tenants situation, in section 3 =85 Further, enterprise data centers = may be organized along businesses, with each business treated as a tenant, thereby supporting multi-tenancy=85,  but this document doesn=92t clearly indicate that a te= nant can also provide services for its tenant recursively.

         &nbs= p;      Regards,

         &nbs= p;      Jiafeng Zhu

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 3:32 PM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:

 

This message begins a two week call for WG a= doption of the document http://www.ietf.org/id/draft-kumar-sfc-dc-use-case= s-01.txt ending 2nd May 2014. 

 

Please respond to the SFC mailing list with = any statements of approval or disapproval.

 

Please note:

  1. This i= s not WG Last Call. The document is not final, and the WG is expected to mo= dify the document=92s content until there is WG consensus that the content = is solid. Therefore, please don=92t 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 b= egin a dialog about how best to address them. 
    4. <= /ol>
--_000_CF850D251FD73jguicharciscocom_-- From nobody Tue Apr 29 09:56: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 C46231A08DB for ; Tue, 29 Apr 2014 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 zzh9-X2ei-Iy for ; Tue, 29 Apr 2014 09:56:34 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by ietfa.amsl.com (Postfix) with ESMTP id 727D61A08EB for ; Tue, 29 Apr 2014 09:56:33 -0700 (PDT) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailout01.vodafone.com (Postfix) with ESMTP id EA79E2E268E for ; Tue, 29 Apr 2014 18:56:30 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id D47D62E0B44; Tue, 29 Apr 2014 18:56:30 +0200 (CEST) Received: from AVOEXC04W.internal.vodafone.com (145.230.15.142) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 29 Apr 2014 18:56:30 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.132]) by AVOEXC04W.internal.vodafone.com ([145.230.15.142]) with mapi id 14.03.0146.002; Tue, 29 Apr 2014 18:56:29 +0200 From: "Haeffner, Walter, Vodafone DE" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsX4roAgBD852A= Date: Tue, 29 Apr 2014 16:56:29 +0000 Message-ID: References: <5351B460.5040709@joelhalpern.com> In-Reply-To: <5351B460.5040709@joelhalpern.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JLW_GtE1lHVIvYyM7b-Ydhwi-0E Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 29 Apr 2014 16:56:40 -0000 I also support this draft. Being on DC level this draft will complement the= other use case drafts. Beside typical FW or DPI etc. there should be not t= hat much overlap with the more carrier services oriented use case drafts. Cheers, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern Gesendet: Samstag, 19. April 2014 01:25 An: Jim Guichard (jguichar); sfc@ietf.org Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 I support adoption of this document by the working group. It is a good sta= rting point for addressing the material it covers, and the working group sh= ould cover that material. Yours, Joel On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > This message begins a two week call for WG adoption of the document=20 > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd=20 > May 2014. > > Please respond to the SFC mailing list with any statements of approval=20 > or disapproval. > > 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. Therefore, 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 them. > > > > _______________________________________________ > 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 nobody Tue Apr 29 16:35: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 8C0951A0953 for ; Tue, 29 Apr 2014 16:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] 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 4gvvJckTtHZP for ; Tue, 29 Apr 2014 16:35:10 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC5A1A0948 for ; Tue, 29 Apr 2014 16:35:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,954,1389704400"; d="scan'208";a="200137349" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 30 Apr 2014 09:35:08 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7423"; a="170226666" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcani.tcif.telstra.com.au with ESMTP; 30 Apr 2014 09:35:08 +1000 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Wed, 30 Apr 2014 09:35:07 +1000 From: "Pham, Chuong D" To: "Haeffner, Walter, Vodafone DE" , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Wed, 30 Apr 2014 09:35:07 +1000 Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: Ac9j4EvX6hlC2l/oS1GlM2Z1MOZmswAIcZLQ Message-ID: <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> References: <5351B460.5040709@joelhalpern.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CYmD9xMAwqCMTDC6fQ8bYGoJb5Y Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 29 Apr 2014 23:35:12 -0000 Separate drafts for pockets of environments will most likely overlook the o= pportunities for identifying commonalities, synergies and reuse factors bet= ween similar use cases for different environments. This is the painful situ= ation today where silos exist while at this point in time where Mobile, Fix= ed Broadband and Data Centre are seeing strong forces towards convergence w= ith SDN, NFV and Cloud technologies. An overall draft such as draft-liu or similar must exist as a common refere= nce point for more detailed level drafts addressing use cases for specific/= pockets of environments while allowing for future migration/convergence. Unless draft-kumar co-exists with high level draft-liu, I see more harm in = divergence rather than benefits therefore I disapprove. Regards, Chuong -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Wednesday, 30 April 2014 2:56 AM To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 I also support this draft. Being on DC level this draft will complement the= other use case drafts. Beside typical FW or DPI etc. there should be not t= hat much overlap with the more carrier services oriented use case drafts. Cheers, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern Gesendet: Samstag, 19. April 2014 01:25 An: Jim Guichard (jguichar); sfc@ietf.org Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 I support adoption of this document by the working group. It is a good sta= rting point for addressing the material it covers, and the working group sh= ould cover that material. Yours, Joel On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > This message begins a two week call for WG adoption of the document=20 > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd=20 > May 2014. > > Please respond to the SFC mailing list with any statements of approval=20 > or disapproval. > > 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. Therefore, 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 them. > > > > _______________________________________________ > 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 nobody Tue Apr 29 18:33:21 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 4D3181A09CC for ; Tue, 29 Apr 2014 18:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 Mf6TO9W3bNes for ; Tue, 29 Apr 2014 18:33:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F3F211A09C2 for ; Tue, 29 Apr 2014 18:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4898; q=dns/txt; s=iport; t=1398821592; x=1400031192; h=from:to:subject:date:message-id:mime-version; bh=ZdbKxgOcjSz6CjKl794IS25+9CFro1M7w1pu018bnjo=; b=WE3gcnm3W7j2u6ENJp59fIa50tdROYsCstB43D7Bsabo6rdS1lhyty2W 41XDiJN2C0O3THqJWGZNDaSYIXIaRmVraNBzPhvarkpvu4Wtau1h/BLIL IqAKIufxDbhL2XYa6JiuqVK8XwRLwItI0IdwHZMNa8XLBzWdMQmishTgd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAOlRYFOtJV2b/2dsb2JhbABZgkJET1fEZ4EmFnSCJQECBB1RHQEIBA0DAQIoORQJCgQBEgmIOA3JexeNbFIehDMEmRCSY4Mxgis X-IronPort-AV: E=Sophos;i="4.97,955,1389744000"; d="scan'208,217";a="321427044" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 30 Apr 2014 01:33:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3U1XBVp031636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Apr 2014 01:33:11 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 20:33:11 -0500 From: "Larry Kreeger (kreeger)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPZBQkU8UhsrhhTUWWEhfLxMVVkQ== Date: Wed, 30 Apr 2014 01:33:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.155.166.41] Content-Type: multipart/alternative; boundary="_000_CF859FFCF2D8Akreegerciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZLPO1JaNem_XExSlyKW7yjvTdN8 Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 30 Apr 2014 01:33:15 -0000 --_000_CF859FFCF2D8Akreegerciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable SFC WG Chairs, This draft is well written. It clearly lays out the use cases, drawbacks a= nd derived SFC requirements for both Enterprise and Service Provider data c= enters. I think it is an very good starting point for a WG data center use= case draft. I would not add any more use cases to it unless they drive di= fferent drawbacks and/or requirements. I support WG adoption. Thanks, Larry From: "Jim Guichard (jguichar)" > Date: Friday, April 18, 2014 3:31 PM To: "sfc@ietf.org" > Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e 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 them. --_000_CF859FFCF2D8Akreegerciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
SFC WG Chairs,

This draft is well written.  It clearly lays out the use cases, d= rawbacks and derived SFC requirements for both Enterprise and Service Provi= der data centers.  I think it is an very good starting point for a WG = data center use case draft.  I would not add any more use cases to it unless they drive different drawbacks and/or requ= irements.  I support WG adoption.

Thanks, Larry

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, April 18, 2014 3:31 P= M
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for adoption of= draft-kumar-sfc-dc-use-cases-01

Dear WG:

This message begins a two week call for WG adoption of the document&nb= sp;h= ttp://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2= nd May 2014. 

Please respond to the SFC mailing list with any statements of approval= or disapproval.

Please note:
  1. This is not WG Last Call. The document is not final, and the WG is expe= cted to modify the document=92s content until there is WG consensus that th= e content is solid. Therefore, please don=92t oppose adoption just because = you want to see changes to its content.
  2. If you have objections to a= doption 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 c= ontent, by all means raise those issues and we can begin a dialog about how= best to address them. 
 --_000_CF859FFCF2D8Akreegerciscocom_-- From nobody Tue Apr 29 23:54: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 D5C5F1A6F0A for ; Tue, 29 Apr 2014 23:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Ep-nDRdBdEEZ for ; Tue, 29 Apr 2014 23:54:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6F1A6EF5 for ; Tue, 29 Apr 2014 23:54:04 -0700 (PDT) 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 BDQ98757; Wed, 30 Apr 2014 06:54:02 +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, 30 Apr 2014 07:52:46 +0100 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Apr 2014 07:54:01 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.143]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 14:53:57 +0800 From: "Liushucheng (Will)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZspytVw Date: Wed, 30 Apr 2014 06:53:57 +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_C9B5F12337F6F841B35C404CF0554ACB5FEBB8D7SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZHSuz6cVCpnt-uxoQYaFjKOT0jk Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 30 Apr 2014 06:54:07 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FEBB8D7SZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As I explained the reason replied in another thread "Re: [sfc] Progression = of SFC use case documents", I don't support the adoption of this draft. Regards, Will (Shucheng LIU) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, April 19, 2014 6:32 AM To: sfc@ietf.org Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Dear WG: This message begins a two week call for WG adoption of the document http://= www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd May 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u 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 them. --_000_C9B5F12337F6F841B35C404CF0554ACB5FEBB8D7SZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= /p>

As I explained the reason= replied in another thread “Re: [sfc] Progression of SFC use case doc= uments”, I don’t support the adoption of this draft.=

 <= /p>

Regards,

Will (Shucheng LIU)

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, April 19, 2014 6:32 AM
To: sfc@ietf.org
Subject: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<= o:p>

 

Dear WG:

 

This message begins a two we= ek call for WG adoption of the document http://www.ietf.org/id/draft-kumar= -sfc-dc-use-cases-01.txt ending 2nd May 2014. 

 

Please respond to the SFC ma= iling list with any statements of approval or disapproval.

 

Please note:

1.  &nbs= p; This is not WG Last = Call. The document is not final, and the WG is expected to modify the docum= ent’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you w= ant to see changes to its content.

2.  &nbs= p; If you have objectio= ns to adoption of the document, please state your reasons why, and explain = what it would take to address your concerns.

3.  &nbs= p; If you have issues w= ith the content, by all means raise those issues and we can begin a dialog = about how best to address them. 

--_000_C9B5F12337F6F841B35C404CF0554ACB5FEBB8D7SZXEMA509MBSchi_-- From nobody Wed Apr 30 00:02: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 2B7531A6EE8 for ; Wed, 30 Apr 2014 00:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 nOwR02pynuoj for ; Wed, 30 Apr 2014 00:02:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 11FCD1A6EE0 for ; Wed, 30 Apr 2014 00:02:29 -0700 (PDT) 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 BGG05289; Wed, 30 Apr 2014 07:02:26 +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; Wed, 30 Apr 2014 08:01:27 +0100 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Apr 2014 08:02:25 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.62]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 15:02:18 +0800 From: "Hongyu Li (Julio)" To: "Pham, Chuong D" , "Haeffner, Walter, Vodafone DE" , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsXfiUAgBDdAICAAG9hgIABAtmw Date: Wed, 30 Apr 2014 07:02:17 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9F783D@SZXEMA509-MBX.china.huawei.com> References: <5351B460.5040709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Tmpgw4UvktCLeo-zuhJE_Zbf2yQ Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 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, 30 Apr 2014 07:02:32 -0000 Q2FuJ3QgYWdyZWUgbW9yZS4NCg0KSG9uZ3l1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBo YW0sIENodW9uZyBEDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDMwLCAyMDE0IDc6MzUgQU0NClRv OiBIYWVmZm5lciwgV2FsdGVyLCBWb2RhZm9uZSBERTsgSm9lbCBNLiBIYWxwZXJuOyBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnDQpDYzogSmVmZnJleSBOYXBwZXIgKGplbmFw cGVyKSAoamVuYXBwZXJAY2lzY28uY29tKQ0KU3ViamVjdDogUmU6IFtzZmNdIENhbGwgZm9yIGFk b3B0aW9uIG9mIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZXMtMDENCg0KU2VwYXJhdGUgZHJh ZnRzIGZvciBwb2NrZXRzIG9mIGVudmlyb25tZW50cyB3aWxsIG1vc3QgbGlrZWx5IG92ZXJsb29r IHRoZSBvcHBvcnR1bml0aWVzIGZvciBpZGVudGlmeWluZyBjb21tb25hbGl0aWVzLCBzeW5lcmdp ZXMgYW5kIHJldXNlIGZhY3RvcnMgYmV0d2VlbiBzaW1pbGFyIHVzZSBjYXNlcyBmb3IgZGlmZmVy ZW50IGVudmlyb25tZW50cy4gVGhpcyBpcyB0aGUgcGFpbmZ1bCBzaXR1YXRpb24gdG9kYXkgd2hl cmUgc2lsb3MgZXhpc3Qgd2hpbGUgYXQgdGhpcyBwb2ludCBpbiB0aW1lIHdoZXJlIE1vYmlsZSwg Rml4ZWQgQnJvYWRiYW5kIGFuZCBEYXRhIENlbnRyZSBhcmUgc2VlaW5nIHN0cm9uZyBmb3JjZXMg dG93YXJkcyBjb252ZXJnZW5jZSB3aXRoIFNETiwgTkZWIGFuZCBDbG91ZCB0ZWNobm9sb2dpZXMu DQoNCkFuIG92ZXJhbGwgZHJhZnQgc3VjaCBhcyBkcmFmdC1saXUgb3Igc2ltaWxhciBtdXN0IGV4 aXN0IGFzIGEgY29tbW9uIHJlZmVyZW5jZSBwb2ludCBmb3IgbW9yZSBkZXRhaWxlZCBsZXZlbCBk cmFmdHMgYWRkcmVzc2luZyB1c2UgY2FzZXMgZm9yIHNwZWNpZmljL3BvY2tldHMgb2YgZW52aXJv bm1lbnRzIHdoaWxlIGFsbG93aW5nIGZvciBmdXR1cmUgbWlncmF0aW9uL2NvbnZlcmdlbmNlLg0K DQpVbmxlc3MgZHJhZnQta3VtYXIgY28tZXhpc3RzIHdpdGggaGlnaCBsZXZlbCBkcmFmdC1saXUs IEkgc2VlIG1vcmUgaGFybSBpbiBkaXZlcmdlbmNlIHJhdGhlciB0aGFuIGJlbmVmaXRzIHRoZXJl Zm9yZSBJIGRpc2FwcHJvdmUuDQoNClJlZ2FyZHMsDQpDaHVvbmcNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFlZmZuZXIsIFdhbHRlciwgVm9kYWZvbmUgREUgW21haWx0 bzp3YWx0ZXIuaGFlZmZuZXJAdm9kYWZvbmUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCAzMCBBcHJp bCAyMDE0IDI6NTYgQU0NClRvOiBKb2VsIE0uIEhhbHBlcm47IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBzZmNAaWV0Zi5vcmcNCkNjOiBKZWZmcmV5IE5hcHBlciAoamVuYXBwZXIpIChqZW5hcHBl ckBjaXNjby5jb20pDQpTdWJqZWN0OiBSZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJh ZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMQ0KDQpJIGFsc28gc3VwcG9ydCB0aGlzIGRyYWZ0 LiBCZWluZyBvbiBEQyBsZXZlbCB0aGlzIGRyYWZ0IHdpbGwgY29tcGxlbWVudCB0aGUgb3RoZXIg dXNlIGNhc2UgZHJhZnRzLiBCZXNpZGUgdHlwaWNhbCBGVyBvciBEUEkgZXRjLiB0aGVyZSBzaG91 bGQgYmUgbm90IHRoYXQgbXVjaCBvdmVybGFwIHdpdGggdGhlIG1vcmUgY2FycmllciBzZXJ2aWNl cyBvcmllbnRlZCB1c2UgY2FzZSBkcmFmdHMuDQoNCkNoZWVycywgV2FsdGVyDQoNCg0KLS0tLS1V cnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gSm9lbCBNLiBIYWxwZXJuDQpHZXNlbmRldDogU2Ft c3RhZywgMTkuIEFwcmlsIDIwMTQgMDE6MjUNCkFuOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsg c2ZjQGlldGYub3JnDQpCZXRyZWZmOiBSZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJh ZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMQ0KDQpJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhp cyBkb2N1bWVudCBieSB0aGUgd29ya2luZyBncm91cC4gIEl0IGlzIGEgZ29vZCBzdGFydGluZyBw b2ludCBmb3IgYWRkcmVzc2luZyB0aGUgbWF0ZXJpYWwgaXQgY292ZXJzLCBhbmQgdGhlIHdvcmtp bmcgZ3JvdXAgc2hvdWxkIGNvdmVyIHRoYXQgbWF0ZXJpYWwuDQoNCllvdXJzLA0KSm9lbA0KDQpP biA0LzE4LzE0LCA2OjMxIFBNLCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSB3cm90ZToNCj4gRGVh ciBXRzoNCj4NCj4gVGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNhbGwgZm9yIFdHIGFk b3B0aW9uIG9mIHRoZSBkb2N1bWVudCANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1r dW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxLnR4dCBlbmRpbmcgMm5kIA0KPiBNYXkgMjAxNC4NCj4N Cj4gUGxlYXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5nIGxpc3Qgd2l0aCBhbnkgc3RhdGVt ZW50cyBvZiBhcHByb3ZhbCANCj4gb3IgZGlzYXBwcm92YWwuDQo+DQo+IFBsZWFzZSBub3RlOg0K Pg0KPiAgMS4gVGhpcyBpcyBub3QgV0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMgbm90IGZp bmFsLCBhbmQgdGhlIFdHIGlzDQo+ICAgICBleHBlY3RlZCB0byBtb2RpZnkgdGhlIGRvY3VtZW50 J3MgY29udGVudCB1bnRpbCB0aGVyZSBpcyBXRw0KPiAgICAgY29uc2Vuc3VzIHRoYXQgdGhlIGNv bnRlbnQgaXMgc29saWQuIFRoZXJlZm9yZSwgcGxlYXNlIGRvbid0IG9wcG9zZQ0KPiAgICAgYWRv cHRpb24ganVzdCBiZWNhdXNlIHlvdSB3YW50IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50 Lg0KPiAgMi4gSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1l bnQsIHBsZWFzZSBzdGF0ZQ0KPiAgICAgeW91ciByZWFzb25zIHdoeSwgYW5kIGV4cGxhaW4gd2hh dCBpdCB3b3VsZCB0YWtlIHRvIGFkZHJlc3MgeW91cg0KPiAgICAgY29uY2VybnMuDQo+ICAzLiBJ ZiB5b3UgaGF2ZSBpc3N1ZXMgd2l0aCB0aGUgY29udGVudCwgYnkgYWxsIG1lYW5zIHJhaXNlIHRo b3NlIGlzc3Vlcw0KPiAgICAgYW5kIHdlIGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91dCBob3cgYmVz dCB0byBhZGRyZXNzIHRoZW0uDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBs aXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg== From nobody Wed Apr 30 02:12: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 0C0081A076F for ; Wed, 30 Apr 2014 02:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 bOmqq7OcnvHU for ; Wed, 30 Apr 2014 02:12:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCF21A0317 for ; Wed, 30 Apr 2014 02:12:41 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2DAAB324451 for ; Wed, 30 Apr 2014 11:12:39 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 117024C015 for ; Wed, 30 Apr 2014 11:12:39 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 30 Apr 2014 11:12:33 +0200 From: To: BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" Date: Wed, 30 Apr 2014 11:12:32 +0200 Thread-Topic: IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QEy65hQ Message-ID: <8100_1398849159_5360BE87_8100_187_11_7ca5dab3-5425-4bb5-9cd9-fd8184921305@PUEXCH41.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@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_7ca5dab354254bb59cd9fd8184921305PUEXCH41nanterrefrancet_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.25.80022 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ru3h8EhDVeDhkVYgxczw11T7e0A Subject: Re: [sfc] IPR related to draft-ietf-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, 30 Apr 2014 09:12:45 -0000 --_000_7ca5dab354254bb59cd9fd8184921305PUEXCH41nanterrefrancet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I do not clearly understand how an IPR can apply to a problem statement doc= ument. As proposed by other contributors on this ml, I would suggest to remove sec= tion 3 of this document so that only problem space is described and discuss= ed. It would be more coherent with SFC charter. David De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I'm surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3). I'm re-iterating my comment to remove section 3 from the PS draft as it see= ms this is the only part that is close to the solution part than the proble= m discussion. Cheers, Med ___________________________________________________________________________= ______________________________________________ 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_7ca5dab354254bb59cd9fd8184921305PUEXCH41nanterrefrancet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= ,

 

I do not clearly understa= nd how an IPR can apply to a problem statement document. =

As proposed by other contributors = on this ml, I would suggest to remove section 3 of this document so that on= ly problem space is described and discussed. It would be more coherent with= SFC charter.

 

David

 =

De : sf= c [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair= @orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0&n= bsp;: sfc@ietf.org
Objet : [sfc] IPR related to draft-ie= tf-sfc-problem-statement

 

Dear all,

<= p class=3DMsoNormal> 

When checkin= g the tracker, I found there is an IPR disclosure for the problem statement= document:

https://datatracker.ietf.org/ipr/search/?option=3Ddocu= ment_search&id=3Ddraft-ietf-sfc-problem-statement

 

I̵= 7;m surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3).

 

I’m re-iterating my= comment to remove section 3 from the PS draft as it seems this is the only= part that is close to the solution part than the problem discussion. =

 

Cheers,

Med<= /p>

_____________________________________________________________=
____________________________________________________________

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_7ca5dab354254bb59cd9fd8184921305PUEXCH41nanterrefrancet_-- From nobody Wed Apr 30 10:08: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 018141A0798 for ; Wed, 30 Apr 2014 10:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3P5aQlaz64qU for ; Wed, 30 Apr 2014 10:08:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6091A0910 for ; Wed, 30 Apr 2014 10:08:25 -0700 (PDT) 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 BGG63146; Wed, 30 Apr 2014 17:08:23 +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; Wed, 30 Apr 2014 18:06:16 +0100 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, 30 Apr 2014 18:07:15 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 10:06:57 -0700 From: Linda Dunbar To: Ron Parker , "Liushucheng (Will)" Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QAx+dPQAArkYRAAHO6UkAAuIUkAALwm9RA= Date: Wed, 30 Apr 2014 17:06:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CFFA6E@dfweml701-chm.china.huawei.com> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.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_4A95BA014132FF49AE685FAB4B9F17F645CFFA6Edfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rmR_tMXv3tmvVYkoITQJq9Oe08k Cc: Jiangyuanlong , BOUCADAIR Mohamed IMT/OLN , "christian.jacquenet@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-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, 30 Apr 2014 17:08:32 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645CFFA6Edfweml701chmchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1. Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Saturday, April 26, 2014 11:19 AM To: Liushucheng (Will) Cc: Jiangyuanlong; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org; christian.jacqu= enet@orange.com Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement +1 Ron On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" > wrote: +1. According to what we have agreed on the charter about the PS, "This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining." The part related to explicit architecture should be merged into the archite= cture document. Regards, Will (Shucheng LIU) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Friday, April 25, 2014 7:35 PM To: christian.jacquenet@orange.com; = BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement +1, Section 3 addresses the architectural elements, which should be conside= red in a separate architecture document. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of christian.jacquenet@or= ange.com Sent: Friday, April 25, 2014 2:23 PM To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement WG, I'd like to second Med's comment: an IPR disclosure is a bit incongruous fo= r a document that is supposed to document a problem statement and only a pr= oblem statement. From this perspective, the current Section 3 is no less mi= splaced. Cheers, Christian. De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I'm surprised to see such disclosure for a document that is supposed to des= cribe only problems (except section 3). I'm re-iterating my comment to remove section 3 from the PS draft as it see= ms this is the only part that is close to the solution part than the proble= m discussion. Cheers, Med ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645CFFA6Edfweml701chmchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1.

 

Linda

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Saturday, April 26, 2014 11:19 AM
To: Liushucheng (Will)
Cc: Jiangyuanlong; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org; christia= n.jacquenet@orange.com
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

+1

 

  Ron

 


On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" <liushucheng@huawei.com> wrote:

+1.

 

According to what we h= ave agreed on the charter about the PS,

 “This docu= ment will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.”= ;

The part related to ex= plicit architecture should be merged into the architecture document.=

 

Regards,

Will (Shucheng LIU)

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong
Sent: Friday, April 25, 2014 7:35 PM
To: christian.jacq= uenet@orange.com; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

+= 1, Section 3 addresses the architectural elements, which should be consider= ed in a separate architecture document.

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of chris= tian.jacquenet@orange.com
Sent: Friday, April 25, 2014 2:23 PM
To: BOUCADAIR Mohamed IMT/OLN; sfc@i= etf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

WG,

 

I’d like to second Med’s comment= : an IPR disclosure is a bit incongruous for a document that is supposed to= document a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplaced.<= o:p>

 

Cheers,

 

Christian.

 

De :<= /span> sfc [mailto:= sfc-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0 : sfc@ietf.org
Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,

 

When checking the tracker, I fo= und there is an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?option=3Ddocument_se= arch&id=3Ddraft-ietf-sfc-problem-statement

 

I’m surprised to see such= disclosure for a document that is supposed to describe only problems (exce= pt section 3).

 

I’m re-iterating my comme= nt to remove section 3 from the PS draft as it seems this is the only part = that is close to the solution part than the problem discussion.

 

Cheers,

Med

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete 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.

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

--_000_4A95BA014132FF49AE685FAB4B9F17F645CFFA6Edfweml701chmchi_-- From nobody Wed Apr 30 12:19: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 2D5A11A886D for ; Wed, 30 Apr 2014 12:19:07 -0700 (PDT) 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 RXCxEaRfTJKl for ; Wed, 30 Apr 2014 12:19:03 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8623F1A8872 for ; Wed, 30 Apr 2014 12:19:03 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id i17so1628365qcy.25 for ; Wed, 30 Apr 2014 12:19:01 -0700 (PDT) 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 :cc:content-type; bh=iaZbN0Xq1bUIfbPKMu36Em2Y7PiIZPdAvG7k6JTKj5o=; b=udwPd+ziH9TftgHFyX2P/0SqWum0wAho9MatrgC1eXRT6gAPbhP7LZhXaDG68JzYdE +LiC1L7CnAra3GIgjO30kQsrs75guve0XmuOJB5tTv6T7FMI6J8ejKLBiCtxxAZ4mi+/ Hi7BbnZQRMqrrUukpn3aA/rQt+Lo2MXee3ESu6BmwmTrlJ4gFIcSR9zdskiAcT8ew5HN 517un04glvQ5a154EVo94Tq2cmGYxt8DnWPzOKcljRS5Ch19pIJ/Ln6TaQMX9h4+/xG8 Kagz/yZPQcnGp7T4k5/tmzZz0VIG0WTdunhxgPhDJstsZTE2b77u2YCnlSjIINyNCfgK qj+A== X-Received: by 10.140.94.39 with SMTP id f36mr7758174qge.64.1398885541575; Wed, 30 Apr 2014 12:19:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Wed, 30 Apr 2014 12:18:41 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CFFA6E@dfweml701-chm.china.huawei.com> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645CFFA6E@dfweml701-chm.china.huawei.com> From: "Andrew G. Malis" Date: Wed, 30 Apr 2014 15:18:41 -0400 Message-ID: To: Linda Dunbar Content-Type: multipart/alternative; boundary=001a113a98d0c9822304f8476be7 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RoFk6F1eFHweidrxAMI5cBe75_Y Cc: "sfc@ietf.org" , "Liushucheng \(Will\)" , "christian.jacquenet@orange.com" , Jiangyuanlong , Ron Parker , BOUCADAIR Mohamed IMT/OLN Subject: Re: [sfc] IPR related to draft-ietf-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, 30 Apr 2014 19:19:07 -0000 --001a113a98d0c9822304f8476be7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also agree with everyone else on this thread. Cheers, Andy On Wed, Apr 30, 2014 at 1:06 PM, Linda Dunbar wrot= e: > +1. > > > > Linda > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker > *Sent:* Saturday, April 26, 2014 11:19 AM > *To:* Liushucheng (Will) > *Cc:* Jiangyuanlong; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org; > christian.jacquenet@orange.com > > *Subject:* Re: [sfc] IPR related to draft-ietf-sfc-problem-statement > > > > +1 > > > > Ron > > > > > On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" > wrote: > > +1. > > > > According to what we have agreed on the charter about the PS, > > =E2=80=9CThis document will provide a summary of the > problem space to be addressed by the SFC working group including > example high-level use cases. Additionally, the working group will > normalize nomenclature and definitions for service function chaining.=E2= =80=9D > > The part related to explicit architecture should be merged into the > architecture document. > > > > Regards, > > Will (Shucheng LIU) > > > > *From:* sfc [mailto:sfc-bounces@ietf.org ] *On > Behalf Of *Jiangyuanlong > *Sent:* Friday, April 25, 2014 7:35 PM > *To:* christian.jacquenet@orange.com; BOUCADAIR Mohamed IMT/OLN; > sfc@ietf.org > *Subject:* Re: [sfc] IPR related to draft-ietf-sfc-problem-statement > > > > +1, Section 3 addresses the architectural elements, which should be > considered in a separate architecture document. > > > > *From:* sfc [mailto:sfc-bounces@ietf.org ] *On > Behalf Of *christian.jacquenet@orange.com > *Sent:* Friday, April 25, 2014 2:23 PM > *To:* BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > *Subject:* Re: [sfc] IPR related to draft-ietf-sfc-problem-statement > > > > WG, > > > > I=E2=80=99d like to second Med=E2=80=99s comment: an IPR disclosure is a = bit incongruous > for a document that is supposed to document a problem statement and only = a > problem statement. From this perspective, the current Section 3 is no les= s > misplaced. > > > > Cheers, > > > > Christian. > > > > *De :* sfc [mailto:sfc-bounces@ietf.org ] *De la > part de* mohamed.boucadair@orange.com > *Envoy=C3=A9 :* jeudi 24 avril 2014 08:27 > *=C3=80 :* sfc@ietf.org > *Objet :* [sfc] IPR related to draft-ietf-sfc-problem-statement > > > > Dear all, > > > > When checking the tracker, I found there is an IPR disclosure for the > problem statement document: > > > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr= aft-ietf-sfc-problem-statement > > > > I=E2=80=99m surprised to see such disclosure for a document that is suppo= sed to > describe only problems (except section 3). > > > > I=E2=80=99m re-iterating my comment to remove section 3 from the PS draft= as it > seems this is the only part that is close to the solution part than the > problem discussion. > > > > Cheers, > > Med > > > --001a113a98d0c9822304f8476be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also agree with everyone else on this thread.

Cheers,
Andy


On Wed, Apr 30, 2014 at 1:06 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

+1.

=C2=A0

Linda

=C2=A0

From: sfc [mai= lto:sfc-bounces@i= etf.org] On Behalf Of Ron Parker
Sent: Saturday, April 26, 2014 11:19 AM
To: Liushucheng (Will)
Cc: Jiangyuanlong; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org; christian.jacquenet@orange.com


Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

=C2=A0

+1

=C2=A0

=C2=A0 Ron

=C2=A0


On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" <liushucheng@huawei.com= > wrote:

+1. <= /u>

=C2=A0

According to what we h= ave agreed on the charter about the PS,

=C2=A0=E2=80=9CThis do= cument will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.=E2=80= =9D

The part related to ex= plicit architecture should be merged into the architecture document.=

=C2=A0

Regards,=

Will (Shucheng LIU)

=C2=A0

From: sfc [mailto:sfc-bounces@i= etf.org] On Behalf Of Jiangyuanlong
Sent: Friday, April 25, 2014 7:35 PM
To: christian.jacquenet@orange.com; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

=C2=A0

+1, S= ection 3 addresses the architectural elements, which should be considered i= n a separate architecture document.

=C2= =A0

From: sfc [mailto:sfc-bounces@i= etf.org] On Behalf Of christian.jacquenet@orange.com
Sent: Friday, April 25, 2014 2:23 PM
To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

=C2=A0

WG,

=C2=A0

I=E2=80=99d like to second Med=E2=80=99s com= ment: an IPR disclosure is a bit incongruous for a document that is suppose= d to document a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplaced.<= u>

=C2=A0

Cheers,

=C2=A0

Christian.

=C2=A0

De=C2=A0:<= /span> sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=C3=A9=C2=A0: jeudi 24 avril 2014 08:27
=C3=80=C2=A0: sfc@= ietf.org
Objet=C2=A0: [sfc] IPR related to draft-ietf-sfc-problem-statement

=C2=A0

Dear all,<= /p>

=C2=A0

When checking the tracker, I fo= und there is an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?op= tion=3Ddocument_search&id=3Ddraft-ietf-sfc-problem-statement

=C2=A0

I=E2=80=99m surprised to see su= ch disclosure for a document that is supposed to describe only problems (ex= cept section 3).

=C2=A0

I=E2=80=99m re-iterating my com= ment to remove section 3 from the PS draft as it seems this is the only par= t that is close to the solution part than the problem discussion.

=C2=A0

Cheers,

Med


--001a113a98d0c9822304f8476be7--